accesskey
Acquista il libro su Apogeonline
Google Memoria dello Spazio

Capitolo 22

La verifica dell'accessibilità

Accessibilità “teorica” e accessibilità “reale”

Il termine tecnico usato in inglese per indicare l’attività di verifica dell’accessibilità è “validation”, che gli sviluppatori italiani che si occupano di accessibilità traducono con “validazione”.

La validation, o validazione, consiste di un insieme di tecniche di analisi, che servono per stabilire se un documento o un sito web sono accessibili, e in che misura. Possiamo considerare la validazione come il necessario atto finale di tutto il complesso lavoro d’implementazione di misure di accessibilità che abbiamo descritto nei capitoli precedenti. Così come un impianto elettrico, per essere considerato a norma, ha bisogno che un tecnico ne certifichi la conformità agli standard, analogamente un sito web può essere definito accessibile secondo gli standard vigenti (le WCAG 1.0, per esempio), solo se qualcuno lo analizza e lo trova corrispondente ai parametri di valutazione previsti per lo standard utilizzato.

Prima di addentrarci, però, nelle procedure di validazione, è opportuno rispondere a un’obiezione che alcuni di tanto in tanto sollevano: può un sito essere considerato accessibile anche se non è mai stato sottoposto a una validazione formale basata sul rispetto di uno standard di accessibilità?

Chi risponde “sì” a questa domanda, di solito distingue tra un’accessibilità teorica, che corrisponderebbe all’esito positivo della validazione fatta da un tecnico seguendo i criteri definiti dallo standard usato come riferimento, e un’accessibilità reale, che sarebbe attestata direttamente dagli utenti beneficiari dell’accessibilità, dimostrando di poter fruire dei contenuti e dei servizi di un sito. Chi fa questa distinzione, pensa probabilmente che l’accessibilità reale sia la sola che meriti di essere perseguita, mentre l’altra, l’accessibilità teorica, sarebbe più che altro un adempimento formale, fatto con lo scopo di applicare un contratto o una norma di legge, senza uno stretto e necessario collegamento con la reale accessibilità del sito validato.

La questione è sottile e necessita a nostro parere di qualche chiarimento.

Innanzitutto, bisogna riconoscere che l’applicazione di alcuni requisiti di accessibilità richiesti dalle WCAG 1.0 è diventata, in seguito all’evoluzione delle tecnologie assistive, un mero adempimento formale, che non porta nulla di positivo per l’accessibilità: è il caso, per esempio, del testo segnaposto nei campi di immissione dei moduli (punto di controllo 10.4), di cui gli screen reader possono ormai fare a meno da anni, e che non serve neppure agli utenti ipovedenti, se si usa la precauzione di formattare i campi modulo in modo da renderli chiaramente distinguibili dallo sfondo. Tale testo, se non è legato a uno script che lo cancella al ricevimento del focus, crea solo problemi agli utenti, anche ai non disabili, i quali sono costretti a cancellarlo prima di scrivere nel campo ciò che desiderano.

Altrettanto inutile per l’accessibilità può essere lo scartare determinate combinazioni di colori primo piano/sfondo, giudicate non valide in base all’algoritmo dei contrasti adottato dalle WCAG 1.0 e dalla legge italiana sull’accessibilità, o utilizzarne altre, giudicate valide, invece, in base allo stesso algoritmo. Ciò perché le due formule su cui si fonda tale algoritmo sono insufficienti rispetto agli scopi per i quali dovrebbero servire, come gli stessi membri del gruppo di lavoro per le WCAG ben sanno, avendo deciso di utilizzare per le WCAG 2.0 un diverso algoritmo e diverse regole per la conformità (si vedano i Capitoli 5 e 20 per informazioni dettagliate sugli algoritmi per la valutazione del contrasto nelle WCAG 1.0 e nelle WCAG 2.0).

Bastano questi due esempi a dimostrare che il rischio di tramutare la verifica dell’accessibilità nella ricerca di una astratta conformità a delle linee guida esiste. Per scongiurare, allora, il rischio di inseguire un’accessibilità più o meno teorica, più o meno lontana dalla cosiddetta “accessibilità reale”, occorrono a nostro avviso due accorgimenti:

  1. disporre di standard per l’accessibilità aggiornati e funzionali. Ciò, naturalmente, non dipende solo dagli sviluppatori, ma da chi produce gli standard. Le WCAG 1.0 risalgono al 1999, un’epoca piuttosto lontana per i tempi di evoluzione del Web. E tuttavia, nell’attesa che le WCAG 2.0 divengano una raccomandazione ufficiale del W3C, quasi tutte le normative sull’accessibilità dei contenuti web prodotte da organismi internazionali e stati nazionali (tra cui anche la legge italiana 4/2004) continuano a basarsi sulle WCAG 1.0. Ciò rende in qualche misura a rischio di inadeguatezza lo sforzo di rendere accessibili i siti web in base a tali normative;
  2. verificare e tarare l’accessibilità per mezzo di test con utenti disabili, anche ricorrendo a prove del tutto informali, nel caso non sia possibile svolgere test scientificamente controllati.

La seconda precauzione è di importanza centrale, perché permette di compensare le eventuali inadeguatezze, dovute all’adozione di linee guida in parte obsolete. Ci è capitato più di una volta, anche nel corso della stesura di questo libro, di imbatterci in contenuti web realizzati nel rispetto delle linee guida per l’accessibilità, i quali poi, alla prova empirica fatta con utenti disabili, si sono rivelati più o meno inaccessibili.

Ciò capita non necessariamente per un difetto tecnico delle linee guida, può capitare anche per altre ragioni, una delle quali è pressoché ineliminabile anche nel più accurato dei regolamenti: la generalità della regola. Proprio perché una linea guida deve valere in tutti i casi, non può tenere conto dell’infinita varietà di situazioni contingenti che possono verificarsi nella realtà (a meno che non sia estrememente specifica, come quella prescrizione della Section 508 che impone di non creare contenuti sfarfallanti con una frequenza compresa tra 2 e 55 Hz). Una regola di accessibilità che si rivela valida in cento casi, nel centounesimo, per una ragione imprevedibile o comunque non prevista, non funzionerà: occorre in quel caso un aggiustamento empirico, che non può essere fatto se non partendo dai riscontri forniti dai beneficiari di quella regola, che sono principalmente gli utenti disabili.

Insomma, la sola applicazione delle linee guida WCAG, o di qualsiasi altro standard per l’accessibilità, non basta a garantire che i contenuti web prodotti siano realmente accessibili, o almeno non basta sempre: a volte è la regola a essere espressa male, a essere troppo generica o a essere invecchiata; altre volte è il giudizio dello sviluppatore che fallisce di comprendere il modo esatto in cui la regola andrebbe applicata; altre volte ancora è il contesto in cui la regola è stata applicata a determinarne il fallimento: per esempio, una tabella di dati può essere troppo complessa per essere compresa navigandola con uno screen reader, anche se le relazioni tra le celle sono state marcate usando gli attributi headers e id esattamente secondo le specifiche, cioè con lo stesso metodo che basta a rendere perfettamente accessibili tabelle meno complesse.

Dunque, i test con gli utenti sono un passo essenziale nella verifica di accessibilità, a tal punto che ogni metodologia standardizzata di validazione li raccomanda, proprio per evitare il rischio di inseguire una conformità puramente astratta.

Invertendo la questione, possiamo chiederci, però, se è lecito considerare i riscontri positivi ricevuti da utenti disabili come sufficienti a garantire di aver sviluppato un sito accessibile, tralasciando i controlli a carico dello sviluppatore definiti nelle procedure di validazione. I sostenitori dell’accessibilità “reale” risponderanno probabilmente di sì, ma è una risposta a nostro avviso insoddisfacente.

Il problema è che, per accertare il possesso di un requisito di accessibilità e il suo livello, occorre una standardizzazione dei metodi di verifica.

I riscontri ricevuti dagli utenti, soprattutto quelli liberi, ottenuti in situazioni non di test, sono certamente importanti, ma nascondono il rischio di una visione parziale dell’accessibilità. Se un non vedente dimostra, o semplicemente dichiara, di poter navigare senza problemi in un sito, ciò non è in nessun caso garanzia che quel sito sia accessibile anche a un ipovedente, a un disabile motorio o a un disabile cognitivo. E lo stesso vale, ovviamente, se i riscontri sono forniti da altre categorie di disabili. Una valutazione attendibile dell’accessibilità deve ottenere riscontri attendibili da un numero sufficiente di utenti, rappresentanti di tutte le categorie beneficiarie dell’accessibilità, possibilmente in situazioni controllate, e mettere insieme il tutto traendone opportunamente le somme.

Insomma, la procedura di validazione, se comprende test con gli utenti e tiene conto dei loro risultati, è proprio lo strumento che serve per superare la distanza tra accessibilità teorica e accessibilità reale. Al contrario, ritenere che un sito sia accessibile solo perché singoli utenti disabili dichiarano di poterlo usare è un’assunzione non verificabile, che può essere ritenuta sufficiente solo in un sito costruito da privati per finalità private. In un sito d’interesse pubblico, invece, soprattutto se c’è un obbligo legale di fornire un servizio senza discriminazioni a tutti i cittadini, è indispensabile che qualsiasi dichiarazione di accessibilità sia garantita da un metodo di verifica standardizzato.

Nel seguito del capitolo esamineremo pertanto i criteri di validazione definiti ufficialmente per le WCAG 1.0 e per i requisiti tecnici della legge 4/2004 nonché i criteri di conformità definiti provvisoriamente per le WCAG 2.0.

Inizio pagina

Salta inserzione pubblicitaria

La validazione secondo le WCAG 1.0

L’Appendice A delle WCAG 1.0, intitolata Validation collegamento esterno, contiene le regole da applicare per la verifica dell’accessibilità.

L’Appendice A delle WCAG 1.0

Il testo dell’appendice comincia con una raccomandazione posta in grassetto, che mette in chiaro i criteri base da seguire nella procedura di validazione:

Verificare l’accessibilità per mezzo di strumenti automatici e della revisione umana. I metodi automatici sono di solito rapidi e convenienti, ma non possono identificare tutti i problemi di accessibilità. La revisione umana può aiutare a garantire chiarezza di linguaggio e facilità di navigazione.

Rimandiamo a una parte successiva del capitolo l’analisi dei metodi automatici di valutazione dell’accessibilità. Concentriamoci ora su un’ulteriore raccomandazione, che segue il testo appena citato e che tocca il problema del “quando”, cioè del momento adatto per cominciare a eseguire le verifiche di accessibilità, momento che non corrisponde, come si potrebbe credere, alla fine del lavoro di sviluppo di un sito:

Cominciare a usare i metodi di validazione durante le prime fasi dello sviluppo. I problemi di accessibilità identificati precocemente sono più facili da correggere e da evitare.

Si tratta di un punto importante: le WCAG 1.0 invitano gli sviluppatori a seguire una procedura che somiglia ai metodi dell’UCD (o User-centered design): nella progettazione centrata sull’utente, ogni fase dello sviluppo di un sito dipende, in un processo circolare, dai risultati delle verifiche precedenti, effettuate per mezzo di test con gli utenti. Un simile modo di procedere, applicato all’accessibilità, diminuisce il rischio di portare troppo avanti una soluzione sbagliata, con il conseguente rischio di non poterla più eliminare, a sito ormai completato.

Segue poi un elenco in dieci punti, che costituisce il cuore della procedura di validazione delle WCAG 1.0. Lo riportiamo in traduzione italiana:

  1. usare uno strumento automatico per l’accessibilità e uno strumento di validazione per i browser. Si noti che gli strumenti software non risolvono tutti i problemi di accessibilità, come per esempio la significatività del testo dei collegamenti, l’applicabilità di un equivalente testuale ecc.;
  2. validare la sintassi (per esempio, HTML, XML ecc.);
  3. validare i fogli di stile (per esempio, CSS);
  4. usare un browser testuale o un emulatore;
  5. usare molteplici browser grafici, nelle seguenti condizioni:
    • suoni e immagini caricati;
    • immagini non caricate;
    • suoni non caricati;
    • senza il mouse;
    • frame, script, fogli di stile e applet non caricati;
  6. usare diversi browser, vecchi e nuovi;
  7. usare un browser vocale, uno screen reader, un software ingrandente, uno schermo piccolo ecc.;
  8. usare dei correttori ortografici e grammaticali. Una persona che legge con un sintetizzatore vocale può non essere in grado di decifrare il miglior tentativo del sintetizzatore di rendere una parola contenente errori ortografici. Eliminare i problemi grammaticali favorisce la comprensione;
  9. rivedere il documento per quanto riguarda la chiarezza e la semplicità. Le statistiche di leggibilità, come quelle generate da alcuni programmi di videoscrittura, possono essere utili indicatori di chiarezza e di semplicità. Meglio ancora, chiedere a un redattore (umano) esperto di rivedere i contenuti scritti quanto alla chiarezza. I redattori possono inoltre incrementare l’usabilità dei documenti, identificando problemi culturali potenzialmente sensibili, che potrebbero sorgere a causa del linguaggio o dell’iconografia usati;
  10. invitare persone con disabilità a esaminare i documenti. Utenti con disabilità esperti o novizi forniranno importanti riscontri sui problemi di accessibilità o di usabilità e sulla loro gravità.

Inizio pagina

I documenti WAI per la valutazione dell’accessibilità

La stringata serie di raccomandazioni per la validazione contenuta nell’Appendice A delle WCAG 1.0 viene ripresa in modo ampio e dettagliato in una sezione del sottosito della Web Accessibility Initiative, dedicato espressamente ai metodi di verifica dell’accessibilità. L’indice della sezione è alla pagina Evaluating Web Sites for Accessibility: Overview collegamento esterno e comprende i seguenti documenti:

  1. Preliminary Review of Web Sites for Accessibility collegamento esterno (“Revisione preliminare dei siti web per l’accessibilità”). Descrive un approccio per identificare rapidamente alcuni potenziali problemi di accessibilità in un sito web;
  2. Conformance Evaluation of Web Sites for Accessibility collegamento esterno (“Valutazione della conformità dei siti web per l’accessibilità”). Descrive un approccio per determinare se un sito web soddisfa i requisiti di uno standard di accessibilità come le WCAG;
  3. Evaluation Approaches for Specific Contexts collegamento esterno (“Approcci di valutazione per specifici contesti”). Descrive metodi per valutare l’accessibilità durante il processo di sviluppo, il monitoraggio continuo, la valutazione di siti datati e di pagine web generate dinamicamente;
  4. Involving Users in Web Accessibility Evaluation collegamento esterno (“Coinvolgere gli utenti nella valutazione dell’accessibilità web”). Fornisce indicazioni su come includere utenti con disabilità nella valutazione dell’accessibilità durante l’intero processo di sviluppo;
  5. Selecting Web Accessibility Evaluation Tools collegamento esterno (“Selezionare gli strumenti di valutazione dell’accessibilità web”). Fornisce indicazioni per la scelta di strumenti ausiliari per la valutazione dell’accessibilità.
  6. Web Accessibility Evaluation Tools List Search collegamento esterno (“Ricerca nell’elenco degli strumenti di valutazione dell’accessibilità web”). Fornisce un elenco completo di strumenti software per la valutazione dell’accessibilità web, che può essere interrogato e ordinato dall’utente;
  7. Using Combined Expertise to Evaluate Web Accessibility collegamento esterno (“Usare competenze combinate per valutare l’accessibilità web”). Descrive la composizione, l’addestramento e le operazioni delle squadre di revisori addette a valutare l’accessibilità dei siti web;
  8. Template for Accessibility Evaluation Reports collegamento esterno (“Modello per resoconti di valutazione dell’accessibilità”). Presenta un modello di formulario per comunicare i risultati delle valutazioni di accessibilità.

[Inizio approfondimento] “Valutare l’accessibilità dei siti web”

Una versione parziale, risalente al Novembre 2002, dei documenti sopra citati è disponibile nella traduzione italiana all’indirizzo http://www.diodati.org/w3c/wai/valuta.htm collegamento esterno. Comprende i numeri 1, 2 e 3 del precedente elenco. [Fine approfondimento]

Esamineremo adesso i concetti principali esposti negli otto documenti elencati.

La revisione preliminare dell’accessibilità

La revisione preliminare è una verifica di accessibilità ristretta, limitata solo a certi gruppi di pagine e ad alcuni metodi di valutazione, che ha lo scopo di identificare i principali problemi di accessibilità di un sito web e di segnalarli affinché possano essere eliminati. Non ha invece lo scopo di verificare il livello di conformità alle linee guida di riferimento (nel nostro caso, le WCAG 1.0).

Chi effettua una revisione preliminare non deve essere necessariamente un tecnico del codice. È sufficiente che sia in grado di scaricare dal Web e utilizzare alcuni software e che sia in grado di cambiare le impostazioni predefinite dei browser.

Il documento WAI Preliminary Review of Web Sites for Accessibility suddivide la revisione preliminare nelle seguenti cinque fasi:

  1. selezionare un campione rappresentativo di pagine. Il campione deve comprendere:
    • tutte le pagine su cui è più probabile che gli utenti giungano al sito;
    • una serie di pagine basate su differenti stili d’impaginazione e differenti funzionalità (per esempio, pagine contenenti tabelle, moduli, contenuti generati da database; grafici o diagrammi; script o oggetti di programmazione).
  2. Esaminare le pagine con browser grafici (amplia l’analoga raccomandazione fornita nell’Appendice A delle WCAG 1.0). Usare un browser grafico – Internet Explorer, Firefox, Safari, Opera ecc. – per effettuare sulle pagine del campione le seguenti prove:
    1. disabilitare le immagini per verificare se sono disponibili testi alternativi appropriati;
    2. disabilitare il suono e verificare se il testo fornisce equivalenti appropriati per i contenuti audio;
    3. usare i controlli del browser per variare la dimensione dei caratteri e verificare che questa cambi sullo schermo conformemente; accertarsi che le pagine siano usabili anche con i caratteri ingranditi;
    4. testare le pagine a differenti risoluzioni dello schermo e/o ridurre proporzionalmente la grandezza della finestra del browser, accertandosi che non sia richiesto lo scorrimento orizzontale; eseguire la stessa prova con differenti browser (o analizzare il codice per vedere se contiene unità di misura assolute), in modo da verificare che gli eventuali problemi dipendano dal contenuto e non dal browser;
    5. cambiare le impostazioni di visualizzazione da colore a scala di grigi (o stampare le pagine in scala di grigi o in bianco e nero) e accertarsi che il contrasto di colore sia sufficiente;
    6. senza servirsi del mouse, usare la tastiera – tipicamente il tasto TAB – per navigare attraverso link e controlli di modulo nelle pagine della selezione, accertandosi di poter accedere a ogni link e controllo di modulo, e che i link indichino chiaramente la loro destinazione.
  3. Esaminare le pagine usando dei browser specializzati. Servirsi di un browser vocale (Home Page Reader) o di un browser testuale (Lynx), per verificare che:
    • le informazioni equivalenti disponibili in un browser grafico restino equivalenti anche se navigate con un browser specializzato;
    • le informazioni siano presentate in una sequenza significativa.
    La prova può essere effettuata anche con uno screen reader, ma, se fatta da un utente cieco, è necessario che sia presente anche un vedente, che possa comparare l’informazione fornita dallo screen reader con quella fornita dai browser grafici. Se la prova viene invece svolta da un vedente con uno screen reader, è importante che navighi a occhi chiusi o a luce spenta, in modo da eliminare la possibilità di essere aiutato da segnali visivi.
  4. Usare degli strumenti automatici per la valutazione dell’accessibilità. Servirsi di almeno due strumenti automatici e prendere nota degli eventuali problemi da essi segnalati (tratteremo questo argomento successivamente).
  5. Fornire un resoconto dei risultati ottenuti. Il resoconto dovrebbe:
    • sintetizzare i tipi di problemi incontrati, come pure gli aspetti positivi che meritano di essere conservati e incrementati nello sviluppo del sito;
    • indicare il metodo con cui i problemi sono stati identificati e specificare chiaramente che non si tratta di una valutazione completa di conformità;
    • raccomandare l’esecuzione dei passi successivi, tra cui la valutazione completa della conformità, che include la validazione del codice di marcatura, insieme con altri test e con metodi per risolvere i problemi identificati.

Inizio pagina

La valutazione della conformità alle linee guida

La valutazione della conformità a uno standard per l’accessibilità ha lo scopo di determinare il grado di corrispondenza tra le pagine del sito web esaminato e i requisiti previsti dallo standard. Nel caso delle WCAG 1.0, la valutazione della conformità serve a determinare se il sito analizzato è conforme al livello A, al livello doppia-A o al livello tripla-A delle linee guida, secondo quanto richiede il paragrafo 5 Conformance collegamento esterno della raccomandazione.

Mentre la revisione preliminare può essere effettuata anche da una persona non esperta di linguaggi di marcatura e di accessibilità, la valutazione della conformità, secondo il metodo descritto nel documento Conformance Evaluation of Web Sites for Accessibility, richiede invece:

Il documento tratta una procedura di valutazione della conformità che comprende solo gli aspetti tecnici esaminabili direttamente da uno sviluppatore, ma aggiunge:

Includere gli utenti nella valutazione aiuta a garantire che le soluzioni tecniche di accessibilità siano applicate efficacemente. Le valutazioni che combinano l’accertamento tecnico e i test di usabilità per l’accessibilità possono essere chiamate valutazioni globali [comprehensive evaluations].

Le procedure con gli utenti sono l’oggetto di un altro documento, che analizzeremo successivamente. Elenchiamo ora le procedure per la valutazione della conformità descritte nel documento che stiamo analizzando:

  1. determinare l’estensione della valutazione. Il primo passo consiste nel definire la gamma di pagine web che devono essere sottoposte a verifica e nell’identificare il livello di conformità, tra i tre disponibili nelle WCAG 1.0, a cui il sito aspira. La selezione del campione sottoposto a verifica deve procedere su due livelli:
    1. per la verifica manuale, che è quella fatta usando browser grafici, vocali e testuali, modificando le loro impostazioni così come descritto al punto 2 dell’elenco nel paragrafo precedente, si definisce un insieme di pagine rappresentative del sito, con gli stessi criteri presentati al punto 1 di quello stesso elenco;
    2. per la verifica automatica e semi-automatica, cioè quella fatta con validatori e software di analisi dell’accessibilità, l’ideale è sottoporre ad analisi l’intero sito. Se ciò non fosse possibile, a causa di un numero troppo elevato di pagine o a causa di altri impedimenti, occorre selezionare un campione esteso, contenente “pagine appartenenti a differenti sezioni del sito; pagine basate su differenti modelli grafici; pagine rappresentative di strumenti di sviluppo e processi differenti, comprese quelle generate da database; pagine prodotte sotto differenti linee guida; pagine di contatto; pagine critiche per l’attività del sito”;
  2. usare validatori e software per la valutazione dell’accessibilità. Esistono due principali categorie di software da utilizzare per completare questa fase della procedura:
    1. i validatori della sintassi dei linguaggi usati per codificare i documenti. Tra i validatori disponibili sul Web, segnaliamo quelli del W3C:
      1. W3C Markup Validation Service collegamento esterno, per il controllo del codice HTML e XHTML;
      2. W3C CSS Validation Service collegamento esterno, per il controllo della sintassi dei fogli di stile CSS;
      3. W3C Feed Validation Service collegamento esterno, per il controllo dei cosiddetti feed, cioè quei file XML in formato RSS o ATOM, che sono utilizzati da una serie di software per fornire ai lettori gli elenchi cronologici degli ultimi aggiornamenti pubblicati su un sito;
    2. gli strumenti automatici di analisi dell’accessibilità, di cui, come già anticipato, parleremo successivamente. Vale qui, però, la pena di precisare che i documenti WAI consigliano di usare sempre almeno due strumenti automatici, allo scopo di ridurre il rischio che l’utilizzatore fraintenda il senso delle segnalazioni provenienti da un solo strumento (due software di analisi useranno probabilmente formule differenti per identificare i medesimi problemi di accessibilità, con ciò permettendo agli utenti di confrontarle e di capire meglio il problema a cui entrambi fanno riferimento);
  3. valutare manualmente un campione di pagine rappresentative. Questa fase del lavoro comprende quattro differenti tipi di operazioni:
    1. applicare al campione scelto per la verifica manuale la lista dei punti di controllo delle WCAG 1.0, disponibile in forma di tabelle (una per ciascuna priorità) alla pagina http://www.w3.org/TR/WCAG10/full-checklist.html collegamento esterno. Nel valutare se un punto di controllo è stato applicato oppure no, l’esaminatore deve tener conto della sua applicabilità al contesto. Si applicano, in altre parole, solo i punti di controllo pertinenti: se, per esempio, un documento non contiene frame, non può e non deve soddisfare il punto di controllo 12.1, che richiede di dare a ogni frame un titolo che faciliti la sua identificazione e la navigazione. Inoltre, il confronto con la lista è obbligatorio solo per i punti di controllo che appartengono al livello di conformità che il sito aspira a raggiungere: se aspira al livello A, basta la conformità ai punti di controllo di priorità 1; per il livello doppia-A serve la conformità ai punti di controllo di priorità 1 e di priorità 2; per il livello tripla-A serve la conformità a tutti i 65 punti di controllo, dalla priorità 1 alla 3 compresa (esclusi naturalmente i punti non pertinenti);
    2. esaminare le pagine del campione usando dei browser grafici. Ai sei tipi di verifica descritti al punto 2, lettere a-f, dell’elenco contenuto nel paragrafo sulla verifica preliminare, si aggiunge qui un settimo tipo di controllo manuale, che consiste nell’esaminare le pagine con script, applet e altri oggetti incorporati non caricati. Il riferimento è, in questo caso, alla linea guida 6 delle WCAG 1.0 e in particolare ai punti di controllo 6.1 e 6.3 (si veda il Capitolo 9 per informazioni dettagliate);
    3. esaminare le pagine del campione usando dei browser specializzati. Ripete le indicazioni del punto 3 dell’elenco contenuto nel paragrafo sulla revisione preliminare;
    4. leggere e valutare il contenuto delle pagine del campione. Viene richiesta una valutazione dei contenuti dal punto di vista della chiarezza e della semplicità dei testi, con riferimento al punto di controllo 14.1 delle WCAG 1.0 (si veda il Capitolo 19 per un’analisi approfondita delle tecniche collegate a questo punto di controllo). Per l’esecuzione di tale verifica, il documento WAI consiglia di leggere attentamente il campione di pagine selezionato: il testo è chiaro e semplice in una misura appropriata agli scopi del sito? (per i siti in inglese, si consideri di usare il test Clear and Appropriate Language and Design (CLAD). Per chi desidera maggiori informazioni, il test CLAD è consultabile sul sito dell’organizzazione canadese no profit East End Literacy collegamento esterno, che lo ha realizzato. Per la valutazione di testi in italiano, suggeriamo invece di tenere in considerazione le tecniche che sono state descritte nel Capitolo 19;
  4. predisporre una relazione contenente le conclusioni della valutazione. Il documento WAI consiglia di “riassumere i problemi e le best practice identificati per ciascun tipo di pagina e di URL rappresentativa, e i metodi per mezzo dei quali sono stati identificati”. Si raccomandano inoltre passi ulteriori per il mantenimento e il miglioramento dell’accessibilità, tra cui:
    1. l’eliminazione delle barriere di accessibilità identificate nel corso del processo di valutazione;
    2. l’espansione delle caratteristiche positive del sito;
    3. la manutenzione e il monitoraggio progressivi del sito.

Inizio pagina

Approcci alla valutazione in situazioni e contesti particolari

Il terzo degli otto documenti WAI per la valutazione dell’accessibilità s’intitola Evaluation Approaches for Specific Contexts e contiene una serie di indicazioni pratiche per portare a termine in situazioni e contesti particolari i compiti descritti nei due paragrafi precedenti. Sono quattro le situazioni considerate nel documento:

  1. la valutazione durante il processo di sviluppo. Le valutazioni effettuate in questa fase permettono di identificare e risolvere precocemente eventuali problemi di accessibilità. Tuttavia attuare un procedimento di verifica dell’accessibilità durante il processo di costruzione di un sito è di solito difficile, a causa di vari impedimenti: sviluppo asimmetrico delle parti (modelli, contenuti, funzioni), provvisorietà delle soluzioni adottate, mancanza di contenuti. Date queste limitazioni, la valutazione di accessibilità in fase di sviluppo può essere favorita dalle seguenti precauzioni:
    1. definire requisiti chiari per il livello di accessibilità che ci si aspetta di raggiungere;
    2. includere l’accessibilità nel piano di sviluppo del sito definito nelle riunioni iniziali;
    3. raggiungere un accordo sulle scadenze alle quali effettuare revisioni durante la fase di sviluppo;
    4. fornire agli sviluppatori informazioni sugli approcci di valutazione dell’accessibilità, in modo che possano effettuare essi stessi una valutazione preliminare;
  2. il monitoraggio continuo. Per rendere massima la probabilità che un sito web conservi nel tempo il livello di accessibilità raggiunto, sono consigliate le seguenti precauzioni:
    1. una chiara definizione del livello di conformità atteso e della gamma di pagine a cui esso deve applicarsi all’interno del sito;
    2. l’identificazione del personale responsabile del monitoraggio del sito e delle procedure che deve adottare per rendere rapidamente conformi le pagine trovate non conformi;
    3. la definizione dei software da adoperare per facilitare la valutazione;
    4. la predisposizione di una casella di posta elettronica, e la sua pubblicazione nel sito, a disposizione degli utenti che desiderano inviare riscontri e segnalazioni sull’accessibilità;
    5. l’esecuzione di test automatici o semi-automatici, per identificare i problemi scoperti nel corso della valutazione globale (che non è sempre necessaria, ma serve solo quando un sito viene pubblicato la prima volta o è sottoposto a trasformazioni radicali);
  3. la valutazione di siti non più aggiornati. Può capitare di dover valutare siti datati, non più aggiornati da tempo, affetti da problemi di accessibilità più o meno gravi. In casi del genere, i suggerimenti per la valutazione sono i seguenti:
    1. identificare il proprietario del sito;
    2. determinare se è obbligato o ha interesse a rendere il sito accessibile;
    3. dopo aver terminato la valutazione, fornire al proprietario del sito un elenco dei cambiamenti che si rendono necessari per adeguare il sito alle richieste dell’accessibilità;
    4. identificare e proporre le risorse e la tempistica per effettuare l’adeguamento;
    5. pubblicare sul sito l’elenco dei problemi di accessibilità riscontrati;
  4. la valutazione di pagine web generate dinamicamente. Se all’epoca della pubblicazione delle WCAG 1.0 erano ancora molto comuni i siti composti di pagine statiche assemblate manualmente, oggi, soprattutto nei siti di grandi dimensioni, la regola è, invece, la generazione dinamica delle pagine. In siti di questo tipo, la richiesta di un documento da parte di un browser attiva degli script lato server, che prelevano i contenuti da una o più basi di dati e li inseriscono “al volo” all’interno di modelli grafici e strutturali predefiniti, chiamati template. La valutazione di accessibilità, in un sito dinamico, deve svolgersi in tre fasi:
    1. valutazione del template. Il documento WAI suggerisce di valutare l’accessibilità del template due volte, la prima esaminando il puro modello vuoto come se fosse una normale pagina statica, la seconda dopo avervi aggiunto del testo. Se i template vengono prodotti, come spesso capita, usando un software autoriale, è importante anche verificare se il software utilizzato abbia la capacità di produrre modelli che rispettano le regole di accessibilità definite dalle ATAG (che sono, per l’appunto, le linee guida per l’accessibilità degli strumenti autoriali. Per informazioni generali, si vedano le note introduttive fornite nel Capitolo 1);
    2. valutazione del contenuto. Anche in questo caso il riferimento è alle ATAG. Si tratta, infatti, di valutare la capacità del CMS, cioè del sistema software per la gestione dei contenuti, di conservare e generare informazioni utili per l’accessibilità. Tra le caratteristiche da considerare vi sono: la possibilità di inserire e archiviare testi alternativi per le immagini e sottotitoli per i video, la possibilità di marcare le tabelle con attributi ed elementi per l’accessibilità (summary, header, id ecc.), la possibilità di generare codice di marcatura valido;
    3. valutazione delle pagine complete (template + contenuto). La valutazione delle pagine web generate da database prevede la cattura preliminare del codice di marcatura prodotto “al volo” (può essere fatto selezionando la voce Visualizza sorgente, o equivalente, nel browser utilizzato). L’analisi deve considerare, oltre alle normali valutazioni di accessibilità fatte in base alle WCAG 1.0, anche la capacità della pagina completa generata di conservare le caratteristiche di accessibilità verificate separatamente per il template e per i contenuti. Se per ragioni di praticità non è possibile analizzare l’intero sito, la valutazione dovrebbe essere condotta su un campione ampiamente rappresentativo dei vari tipi di pagina in esso presenti.

Inizio pagina

Coinvolgere gli utenti nella valutazione di accessibilità

Il documento WAI Involving Users in Web Accessibility Evaluation contiene una serie di indicazioni su come includere gli utenti con disabilità, principali beneficiari di siti accessibili, nel processo di valutazione dell’accessibilità. Sono di particolare interesse le considerazioni iniziali, perché spiegano bene l’importanza della verifica fatta con gli utenti:

Allargare la valutazione fino a coinvolgere persone con disabilità aiuta a comprendere meglio le questioni di accessibilità e a implementare soluzioni di accessibilità più efficaci.

Uno dei benefici derivanti dall’includere persone con disabilità è che gli sviluppatori web possono imparare come queste persone interagiscono con il Web e con le tecnologie assistive. Si consideri, per esempio, uno sviluppatore che non abbia idea di come si usi uno screen reader. Per soddisfare la linea guida di accessibilità “Fornire alternative testuali per tutti i contenuti non testuali”, lo sviluppatore potrebbe inserire come testo alternativo: “Quest’immagine è un disegno di una lente d’ingrandimento verde scuro su uno sfondo bianco. Se clicchi su di esso, arriverai alla pagina di Ricerca”. Tuttavia, osservare una persona che usa il sito con uno screen reader mostrerà chiaramente allo sviluppatore che la sua alternativa testuale è inefficace e che “cerca” era tutto quello che serviva.

Esistono modi diversi di coinvolgere utenti con disabilità in una valutazione di accessibilità. Si va dai colloqui informali in ambiente di lavoro o domestico ai veri e propri test di usabilità, condotti con un campione selezionato di utenti, applicando rigidamente i protocolli definiti dalle metodologie di ricerca in uso. Il documento WAI ritiene più efficaci le valutazioni informali condotte nel corso del processo di sviluppo di un sito, piuttosto che un test di usabilità formale, condotto a sito ultimato.

Per valutazione informale, si intende qualcosa di questo tipo: “Una valutazione informale di uno specifico problema di accessibilità può essere semplice come chiedere a una persona nel vostro ufficio che usa uno screen reader di trovare alcuni dati nella bozza preliminare di una tabella di dati che state sviluppando, osservando la sua interazione e discutendo con lei le questioni sorte”.

Per ottenere questo tipo di riscontri, è necessario reperire un campione di utenti disabili, non necessariamente numeroso, e sottoporre a ciascun membro del campione dei semplici compiti da eseguire sui prototipi in corso di sviluppo. Bisogna però fare attenzione al pericolo delle generalizzazioni:

Considerate attentamente tutti i riscontri ed evitate di assumere che le informazioni ricevute da una persona con disabilità si applichino a tutte le persone disabili. Chi ha una disabilità non necessariamente sa come altre persone con la stessa disabilità interagiscono con il Web né conosce a sufficienza le altre disabilità, al punto da poter fornire una valida guida su altri problemi di accessibilità.

Nella scelta del campione è importantissimo riuscire a ottenere la massima rappresentatività possibile, tenendo conto che le variabili che interessano sono principalmente due: il tipo di disabilità e le caratteristiche dell’utente.

Le disabilità che hanno rilevanza per l’accessibilità del Web sono – come il lettore ricorderà dalla lettura del primo capitolo del libro – quelle della vista (cecità, ipovisione, deficit nella visione dei colori), quelle motorie (distrofia, affezioni spastiche, impossibilità di usare gli arti superiori), quelle cognitive e neurologiche (dislessia, ritardo mentale, epilessia).

Le caratteristiche personali che influenzano la valutazione sono ancora più numerose e riguardano l’età, il livello culturale, la lingua parlata, il grado di competenza nell’uso del Web e delle tecnologie assistive, il tipo di lavoro svolto, e altro ancora.

Nella valutazione di accessibilità effettuata con utenti disabili bisognerebbe tener conto nella giusta misura di tutte queste variabili, sia nella formazione del campione sia nelle conclusioni tratte dalle prove effettuate. Per esempio, se un utente mostra di aver problemi nel navigare una tabella di dati, chi svolge la valutazione deve essere in grado di capire a quale delle tre possibilità seguenti va ascritta la causa:

Naturalmente la materia dei test di usabilità, sia pure informali, è molto complessa e non può che essere trattata sommariamente sia nei documenti WAI sia in questo libro, che sono dedicati in primo luogo alle questioni di accessibilità.

Per una serie di utili informazioni sulla scelta del campione e sulle modalità di esecuzione dei test, rimandiamo a Just Ask: Integrating Accessibility Throughout Design collegamento esterno, di Shawn Lawton Henry. Sul sito web dedicato al libro sono presenti delle schede informative e un’appendice con numerosi rimandi a libri e siti web che trattano di usabilità applicata all’accessibilità.

Figure professionali coinvolte nel processo di validazione

Il documento WAI Using Combined Expertise to Evaluate Web Accessibility fornisce informazioni sul tipo di competenze necessarie per svolgere con successo valutazioni di accessibilità attendibili. È interessante leggere la precisazione con cui si apre il documento:

Valutare l’accessibilità dei contenuti web per persone con disabilità richiede diversi tipi di competenze e di prospettive. È possibile che singoli individui valutino efficacemente l’accessibilità web se possiedono addestramento ed esperienza in una vasta gamma di discipline, ma è poco probabile che un sola persona possieda tutte le competenze che un approccio collaborativo può apportare.

Il WAI pone l’accento sull’importanza di una procedura di validazione collaborativa, proprio perché le competenze richieste sono tali che difficilmente un singolo esperto può possederle tutte, o quanto meno in misura sufficiente agli scopi. Infatti:

Un’efficace valutazione dell’accessibilità web richiede più che la semplice esecuzione di uno strumento di valutazione su un sito web. Valutazioni complete ed efficaci richiedono valutatori con una comprensione delle tecnologie web, degli strumenti di valutazione, delle barriere che sperimentano le persone con disabilità, delle tecnologie assistive e degli approcci che le persone con disabilità utilizzano, nonché delle linee guida e delle tecniche di accessibilità.

Il numero di persone coinvolte in un processo di valutazione dell’accessibilità e le modalità di reclutamento non possono essere definiti a priori. Molto dipende dalle disponibilità del soggetto che gestisce il sito web da valutare. In una grande organizzazione, è possibile che vi sia una squadra di professionisti incaricati in pianta stabile di eseguire valutazioni sulla qualità dei siti web pubblicati; oppure è possibile che vengano definiti di volta in volta gruppi differenti di esperti a cui delegare le procedure di valutazione in programma. Se l’organizzazione non dispone delle figure professionali necessarie, può assoldare degli esperti che svolgono attività di valutatori come liberi professionisti oppure delegare completamente l’attività di valutazione a società esterne.

Una piccola realtà, invece, è costretta di solito a fare di necessità virtù, svolgendo internamente le procedure di valutazione dell’accessibilità web oppure cercando di far rientrare in un budget ridotto all’osso un’eventuale attività di valutazione appaltata a terzi.

Proprio a causa della variabilità dei mezzi e delle competenze che, a seconda delle possibilità del soggetto committente, possono essere impiegati nella validazione di un sito, è estremamente importante che le verifiche di accessibilità si svolgano in modo quanto più possibile conforme alla procedura definita dallo standard di accessibilità usato come riferimento (nel caso delle WCAG 1.0, i riferimenti canonici sono l’Appendice A delle linee guida e i documenti WAI analizzati in questo capitolo): cercare di attenersi scrupolosamente alla procedura ridurrà il rischio che valutazioni eseguite in economia di mezzi e di personale producano alla fine dichiarazioni di accessibilità non veritiere.

Inizio pagina

Strumenti software per la valutazione dell’accessibilità

Eccoci finalmente a uno degli argomenti più cari agli sviluppatori interessati alle valutazioni di accessibilità: la scelta e l’uso di strumenti software di valutazione.

Selecting Web Accessibility Evaluation Tools è il documento WAI che spiega come identificare gli strumenti per la valutazione dell’accessibilità adatti alle proprie esigenze: contiene una serie di informazioni di carattere generale sulle capacità di strumenti automatici e semiautomatici e sulle categorie in cui possono essere suddivisi.

La parte più interessante del documento è quella che spiega che cosa gli strumenti di valutazione sono in grado di fare per l’accessibilità e che cosa, invece, non possono fare. La riportiamo di seguito in traduzione italiana, perché rappresenta il punto fondamentale della questione:

Che cosa gli strumenti di valutazione possono fare. Gli strumenti di valutazione dell’accessibilità web possono ridurre significativamente il tempo e lo sforzo richiesti per eseguire le valutazioni. Quando usati con attenzione durante le fasi di progettazione, implementazione e manutenzione dello sviluppo web, tali strumenti possono assistere i loro utilizzatori nel prevenire barriere di accessibilità, nel riparare le barriere incontrate e nel migliorare la qualità complessiva dei siti web. Ecco alcuni dei modi in cui degli strumenti automatici possono aiutare gli utilizzatori a valutare l’accessibilità dei siti web (alcuni strumenti sono in grado di fare entrambe le cose):

Che cosa gli strumenti di valutazione non possono fare. Molti controlli di accessibilità richiedono il giudizio umano e devono essere valutati manualmente usando tecniche differenti. Inoltre, in certi casi gli strumenti di valutazione sono inclini a produrre risultati falsi o equivoci, come il non identificare o non segnalare del codice scorretto. I risultati ottenuti dagli strumenti di valutazione non dovrebbero essere usati per determinare il livello di conformità, a meno che non siano adoperati da valutatori esperti, che comprendono le possibilità e i limiti degli strumenti al fine di ottenere risultati accurati. Gli strumenti di valutazione dell’accessibilità web non possono determinare l’accessibilità dei siti web, al massimo possono aiutare nell’operazione.

L’ultimo punto è della massima importanza. In un passato anche recente, molti siti che si dichiaravano accessibili, esibivano come garanzia per gli utenti un bollino raffigurante un simpatico poliziotto inglese, rilasciato da un software di valutazione automatica, Bobby, attualmente non più disponibile nella versione online (è stato sostituito da uno strumento più avanzato, WebXACT della Watchfire collegamento esterno).

Benché il resoconto mostrato da Bobby al termine del controllo automatico avvisasse chiaramente gli utilizzatori che, al fine di utilizzare i suoi bollini, andavano eseguiti dei controlli manuali che solo un umano poteva svolgere, molti si limitavano a esporre il bollino prodotto automaticamente da Bobby, trascurando di compiere i necessari controlli manuali. Il risultato era quasi inevitabilmente un sito meno accessibile di quanto i bollini esposti dichiarassero (Figura 22.1).

Figura 22.1. Alcuni dei bollini esposti nelle pagine web che dichiaravano – e alcune ancora dichiarano – un livello presunto di accessibilità determinato automaticamente da Bobby.

È bene dunque tenere sempre a mente che gli strumenti automatici possono aiutare un valutatore esperto a compiere il suo lavoro, ma non sono in grado di determinare da soli il grado di conformità di un sito alle WCAG o ad altre linee guida per l’accessibilità. Esaminiamo ora quali sono le categorie di strumenti di valutazione disponibili. Ne possiamo ricavare un’idea dal modulo d’interrogazione avanzata collegamento esterno disponibile sul sito del WAI/W3C mostrato in Figura 22.2.

Figura 22.2. Il modulo per la ricerca avanzata di strumenti software per la valutazione dell’accessibilità, sul sito del WAI/W3C (5/6/2007).

Come si ricava dal modulo, la scelta di uno strumento di valutazione può essere fatta in base a numerose categorie, scelte isolatamente o combinate insieme (in linea generale, più opzioni si selezionano, meno numerosi saranno i risultati ottenuti). Le categorie sono le seguenti:

L’elenco completo presente sul sito WAI/W3C collegamento esterno, aggiornato al 17 marzo 2006, comprende la descrizione di ben 115 strumenti software di valutazione, nonché i link ai siti da cui ciascuno di essi può essere utilizzato direttamente, acquistato o scaricato in locale, a seconda della categoria a cui appartiene.

Non abbiamo qui lo spazio per descriverli tutti compiutamente né servirebbe ai fini di questo libro, il cui scopo è fornire al lettore informazioni e principi di carattere generale. Alcuni degli strumenti nell’elenco WAI sono stati già citati nei capitoli precedenti (i validatori in più di un’occasione; simulatori di deficit della visione nel Capitolo 2; programmi per la verifica dei contrasti di luminosità e colore nei Capitoli 5 e 12). Ci limiteremo, in questo capitolo, a esaminare le caratteristiche principali di tre diversi tipi di strumenti automatici, che rappresentano altrettanti differenti modelli d’interazione con lo sviluppatore nella pratica di valutazione dell’accessibilità: un analizzatore via Web (WebXACT), un analizzatore in locale (HTML Tidy) e le cosiddette barre dell’accessibilità.

Inizio pagina

Watchfire WebXACT

Cominciamo con l’erede di Bobby, quel WebXACT della Watchfire a cui avevano fatto all’inizio del paragrafo precedente. Si tratta di uno strumento online che analizza una pagina web per volta, fornendo un resoconto consultabile anch’esso via Web. Le impostazioni di questo software permettono di specificare lo standard contro il quale si desidera effettuare la valutazione: cioè la legge statunitense Section 508 oppure le WCAG 1.0, per le quali è possibile indicare anche il livello di conformità che si aspira a raggiungere. È indispensabile inserire, ovviamente, l’indirizzo del documento che deve essere valutato per l’accessibilità (Figura 22.3).

Figura 22.3. La maschera per definire i tipi di controlli che WebXACT collegamento esterno eseguirà nel corso della sua valutazione automatica.

L’analisi di WebXACT fornisce vari tipi di informazioni: sul documento in generale, sulla qualità, l’accessibilità e la privacy. Quelle che interessano di più per i nostri fini sono, naturalmente, quelle contenute nella scheda Accessibility.

Figura 22.4. Il sommario degli errori e degli avvertimenti per l’accessibilità, rilevati da WebXACT nel corso di un test di analisi.

In Figura 22.4 è visibile il sommario della scheda, che elenca il numero e le occorrenze di errori e avvertimenti, suddivisi per priorità, che il software ha rilevato nel corso della sua analisi, che avevamo impostato sul livello tripla-A delle WCAG 1.0. La tabella mostra che la pagina esaminata non presenta errori rilevabili in automatico per la priorità 1, mentre ne presenta uno per la priorità 2 e uno per la priorità 3.

L’errore di priorità 2 trovato da WebXACT (Figura 22.5) è un classico esempio di falso positivo, che dimostra la validità della tesi sostenuta nel documento WAI Selecting Web Accessibility Evaluation Tools: gli strumenti automatici possono aiutare un esperto a trovare gli errori presenti in un sito, ma non sono in grado di determinare direttamente in modo affidabile il grado di conformità a uno standard di accessibilità.

Figura 22.5. L’errore di priorità 2 rilevato da WebXACT nel corso della nostra prova.

Proviamo a chiarire in cosa consiste il falso positivo, sperando che l’esempio aiuti i lettori a comprendere meglio limiti e potenzialità degli strumenti software di valutazione. L’errore è presentato come una violazione del punto di controllo 13.1 delle WCAG 1.0, e fa riferimento a un punto del documento di Tecniche HTML per le WCAG, in cui si afferma (si veda anche il commento al punto di controllo 13.1 nel Capitolo 18):

Se su una pagina più collegamenti condividono lo stesso testo visibile, dovrebbero puntare tutti alla medesima risorsa. Questa forma di coerenza andrà a beneficio della progettazione della pagina e pure dell’accessibilità.

In sostanza, WebXACT ha rilevato che nella pagina esaminata vi sono due collegamenti che hanno lo stesso testo ma puntano a risorse differenti, e indica che l’occorrenza da eliminare o da modificare si trova alla riga 177.

Andando a esaminare il codice di marcatura del documento, troviamo che vi sono effettivamente due collegamenti ipertestuali – rispettivamente alle righe 116 e 177 – che hanno lo stesso testo. Li riportiamo nel Listato 22.1.

Listato 22.1 I due collegamenti per i quali è stato riscontrato l’errore indicato in Figura 22.5.

<a href="http://www.diodati.org/w3c/wai/tecnichecss/">Note
sulle Tecniche CSS per le WCAG 1.0</a>


<a href="/w3c/wai/tecnichecss/index.html">Note
sulle Tecniche CSS per le WCAG 1.0</a>

Come noterà chiunque abbia un po’ di esperienza come sviluppatore, i due valori di href evidenziati col grassetto nel listato, sebbene abbiano una forma diversa, rimandano esattamente alla medesima pagina web. Il primo è un URI espresso in forma assoluta e non riporta il nome del file a cui punta, perché sfrutta la capacità del server di servire automaticamente i documenti chiamati index.html quando l’indirizzo termina col nome della directory; il secondo valore è espresso, invece, in forma relativa.

Il software non è in grado di accorgersi che i due valori richiamano la stessa risorsa, ma uno sviluppatore esperto deve essere in grado di rilevarlo, ed è il suo parere finale che stabilisce il livello di conformità alle WCAG, non lo strumento automatico. Pertanto, il documento analizzato può essere conforme al livello doppia-A, nonostante l’errore rilevato da WebXACT, proprio perché si tratta di un errore inesistente, cioè di un falso positivo: non vi sono due testi del collegamento uguali per due risorse differenti, ma due testi del collegamento uguali per la stessa risorsa.

Tuttavia, per la conformità al livello doppia-A della pagina web esaminata da WebXACT, non è ancora sufficiente che non vi siano errori per la priorità 1 e per la priorità 2. Occorre anche eseguire i controlli manuali che il software non è in grado di svolgere, ma che segnala come necessari ai fini della conformità (ecco perché è uno strumento semi-automatico: non è in grado di risolvere automaticamente tutte le questioni di accessibilità originate dal codice, ma richiede a tal fine l’intervento umano).

La Figura 22.6 riporta, a titolo di esempio, i cinque Warnings che WebXACT segnala per la priorità 1.

Figura 22.6. La tabella con i Warning di WebXACT per la priorità 1, con l’indicazione del numero di riga a cui ogni segnalazione fa riferimento.

I primi due Warnings sono originati da qualcosa che il software ha riscontrato nel codice di marcatura, ma non è in grado di valutare direttamente: si tratta dei diciotto file immagine che la pagina web analizzata richiama. Per ciascun file immagine, WebXACT richiede all’utilizzatore umano di valutare due condizioni:

  1. se l’immagine convoglia informazioni importanti, per le quali il testo alternativo breve fornito dall’attributo alt non sia sufficiente. Se la risposta è positiva, per conformità al punto di controllo 1.1 delle WCAG 1.0 occorrerà fornire una descrizione estesa, referenziata, per esempio, per mezzo dell’attributo longdesc;
  2. se l’immagine usa il colore per convogliare informazioni. In tal caso, occorrerà accertarsi che quelle informazioni siano disponibili anche in altra maniera, indipendente dal colore, in accordo con quanto richiede il punto di controllo 2.1 delle WCAG 1.0.

La tabella in Figura 22.6 contiene poi altri tre avvertimenti che non sono originati dall’analisi del codice di marcatura, ma rispondono a fattori di accessibilità che WebXACT non è in alcun modo in grado di controllare. Si tratta delle richieste dei punti di controllo 6.1, 7.1 e 14.1 delle WCAG 1.0, tutti di priorità 1. È pertanto a cura esclusiva dello sviluppatore accertarsi che:

Per la priorità 2, WebXACT segnala inoltre tredici Warnings, dei quali tre soli sono originati da fattori presenti nel codice di marcatura. È inutile analizzarli uno per uno. Il concetto principale dovrebbe essere ormai chiaro, e cioè: non ha alcun senso reclamare la conformità a un qualsiasi livello delle WCAG 1.0, anche in assenza di errori segnalati da WebXACT (o da altro software dotato di caratteristiche simili), se prima non sono state soddisfatte in modo coscienzioso, per mezzo di controlli umani, tutte le richieste di analisi ulteriore sollecitate dai Warnings.

Inizio pagina

HTML Validator con HTML Tidy

Un modello differente di strumento automatico è HTML Validator collegamento esterno, un’estensione per Mozilla e Firefox (Figura 22.7). Questo strumento – basato sulla struttura Open Source di HTML Tidy, un programma sviluppato anni fa da Dave Raggett del W3C – è in grado di rilevare errori e imprecisioni nel codice di marcatura, rispetto alle DTD di HTML e di XHTML. Integra inoltre la capacità di analizzare il codice dal punto di vista dell’accessibilità, eseguendo gli stessi tipi di controlli svolti da WebXACT.

Figura 22.7. HTML Validator 0.8.3.9, installato come estensione di Firefox 2.0 su Windows XP.

Il vantaggio di HTML Validator, rispetto agli strumenti online come WebXACT, è che la sua analisi avviene in locale, sul codice caricato nel browser, e può quindi essere usato anche per esaminare pagine in sviluppo, non ancora pubblicate sul Web.

Inoltre, per il fatto di essere integrato all’interno del browser, permette di ottenere con la massima rapidità le informazioni di valutazione che è in grado di produrre. Grazie, per esempio, a un’icona posta in basso a destra, nella barra di stato del browser, l’utente è informato visivamente circa le caratteristiche salienti di ogni pagina web visitata: un segno di spunta su una sfera verde indica che non sono presenti errori di HTML o di XHTML, una “X” su una sfera rossa indica invece che sono presenti errori e/o avvertimenti (warnings).

Passando con il mouse sull’icona collegata al validatore, compare uno specchietto riassuntivo, che fornisce tre cifre (Figura 22.8). La prima cifra dall’alto indica il numero di errori di codifica rispetto alla DTD di HTML o di XHTML usata nel documento; la seconda cifra indica le imprecisioni che andrebbero corrette; la terza cifra, infine, indica gli avvertimenti che riguardano direttamente l’accessibilità, basati sulla valutazione automatica della conformità del codice alle WCAG 1.0 (il livello contro il quale effettuare la valutazione è configurabile dall’utente).

Figura 22.8. Le informazioni sul codice di marcatura della pagina corrente, fornite da HTML Tidy.

Visualizzando il sorgente della pagina, cosa che può essere fatta anche con un doppio clic sull’icona del Validator, si ottiene il resoconto esteso relativo a validità del codice e accessibilità, visualizzato nella parte inferiore della finestra (Figura 22.9).

Figura 22.9. Il resoconto di HTML Validator è diviso in tre parti: la finestra superiore mostra il codice di marcatura del documento analizzato, la finestra in basso a sinistra l’elenco degli avvertimenti per l’accessibilità, la finestra in basso a destra le spiegazioni relative all’avvertimento selezionato.

Anche con questo strumento di valutazione, così come con WebXACT, è necessario che il valutatore umano ponga attenzione alle segnalazioni. In Figura 22.9 è mostrato un esempio che illustra il concetto. L’avvertimento selezionato nella finestra in basso a sinistra rimanda a un elemento IMG, che appare alle righe 57 e 58 del documento analizzato. Il warning dice “missing ‘alt’ text”, indica cioè un testo alternativo mancante e quindi una potenziale violazione del punto di controllo 1.1 delle WCAG 1.0. In realtà l’attributo alt è presente e deliberatamente vuoto, perché riferito a un’immagine non significativa per la comprensione del contenuto. Non si finirà mai di sottolineare quanto siano importanti l’esperienza e la pazienza del valutatore umano nel controllare ogni singola segnalazione, e quanto sia improvvido, al contrario, affidarsi unicamente agli strumenti di valutazione.

Un’ultima caratteristica importante dell’estensione di Firefox che stiamo analizzando è la sua capacità non solo di valutare, ma anche di “riparare” il codice dei documenti esaminati, grazie all’integrazione con HTML Tidy (Figura 22.10). Il programma è in grado di riformattare il codice di marcatura rendendolo più leggibile, di trasformare codice HTML in codice XHTML (e viceversa), di cambiare la DTD e la codifica dei caratteri, di sostituire eventuali elementi FONT con stili CSS che producono un equivalente aspetto grafico.

Figura 22.10. Le opzioni di ripulitura del codice offerte da HTML Tidy, integrato nell’estensione di Mozilla e Firefox HTML Validator.

Inizio pagina

Le barre dell’accessibilità

Le barre dell’accessibilità sono tra gli strumenti di valutazione più comodi e potenti a disposizione degli sviluppatori. Si tratta di barre contenenti pulsanti e menu, installabili come plug-in all’interno dei principali browser grafici. Forniscono all’utilizzatore un’ampia serie di strumenti interattivi, utili per verificare se il codice di marcatura e le caratteristiche grafiche e strutturali dei documenti caricati corrispondono alle richieste degli standard di accessibilità usati per la valutazione.

Per Internet Explorer, e da poco anche per Opera, è disponibile la Web Accessibility Toolbar collegamento esterno, giunta alla versione 1.2, e che, grazie alla traduzione di Roberto Castaldo per Webaccessibile.org, è disponibile anche in lingua italiana collegamento esterno, nella versione per Internet Explorer. (Alla chiusura del libro, è ancora in elaborazione la versione 2.0 della barra. Per chi desidera testarne in anticipo le funzionalità, è possibile scaricare la versione beta collegamento esterno tradotta in italiano).

Vediamo in sintesi quali sono i principali comandi disponibili in ciascun menu della barra con riferimento alla versione stabile corrente, la 1.2. Il menu Validazioni permette di verificare la correttezza del codice HTML e CSS, per mezzo sia dei validatori del W3C sia di HTML Tidy, ormai già noto al lettore.

Figura 22.11. La Web Accessibility Toolbar nella versione italiana, installata in Internet Explorer 7.

Il menu Ridimensiona contiene una funzione estremamente utile per applicare in modo rapido uno dei criteri di verifica dell’accessibilità suggeriti dall’appendice A delle WCAG 1.0 (nonché dalla metodologia di verifica della legge italiana 4/2004): cioè la visualizzazione della medesima pagina web a risoluzioni differenti. Senza bisogno di cambiare la risoluzione generale del monitor, ma agendo tramite appositi script lato client, le opzioni del menu Ridimensiona permettono, infatti, di modificare dinamicamente la larghezza e l’altezza della finestra del browser, come mostra il triplice esempio riportato in Figura 22.12.





Figura 22.12. La stessa pagina web visualizzata, a partire dall’alto, alle risoluzioni di 640×480, 800×600 e 1024×768, grazie alle opzioni del menu Ridimensiona della Web Accessibility Toolbar.

Il menu CSS consente di fare un’altra delle verifiche richieste dalla procedura di validazione delle WCAG 1.0: il controllo che i contenuti siano leggibili e utilizzabili anche a fogli di stile disabilitati (Figura 22.13). Tra le altre opzioni del menu, c’è la possibilità di visualizzare gli stili associati al documento caricato e di provare modifiche interattive agli stili (funzione utile in fase di sviluppo).

Figura 22.13. La pagina corrente viene mostrata senza fogli di stile, grazie all’applicazione di un’apposita funzione del menu CSS della Web Accessibility Toolbar.

Il menu Immagini permette di ottenere informazioni rapide sui file immagine e sui relativi testi alternativi utilizzati nel documento da valutare. È possibile passare dalla vista normale alla vista con i testi alternativi al posto delle immagini oppure visualizzare in una nuova finestra l’elenco completo delle immagini presenti nel documento, associate al codice di marcatura corrispondente (Figura 22.14).

Figura 22.14. Tramite il menu Immagini della Web Accessibility Toolbar si accede a una pagina contenente tutte le immagini del documento, associate al relativo codice di marcatura.

Il menu Colori dà accesso a una serie di funzioni per il controllo dell’accessibilità del contrasto cromatico e di luminosità, in base sia all’algoritmo delle WCAG 1.0 sia a quello delle WCAG 2.0. Tra le funzioni più interessanti, citiamo la possibilità di visualizzare la pagina corrente in scala di grigi e la possibilità di simulare la visione alterata di chi soffre di deficit nella percezione dei colori o di cataratta (Figura 22.15). Per chi non ha idea di quanto possa essere faticoso leggere un testo piccolo e poco contrastato se la propria vista è offuscata, consigliamo vivamente l’utilizzo di questo simulatore.

Figura 22.15. Il simulatore di visione alterata, a cui dà accesso il menu Colori della barra dell’accessibilità.

Uno dei menu più complessi e utili è il menu Struttura, che dà accesso a una serie di funzioni che consentono di visualizzare interattivamente numerose informazioni strutturali, che possono apparire sovrapposte ai contenuti del documento oppure essere caricate in una nuova pagina. È possibile così ottenere la gerarchia dei titoli (elementi H1-H6), l’elenco e la posizione dei tasti di accesso rapido (attributo accesskey), l’ordine di tabulazione del documento, l’esposizione di acronimi e abbreviazioni, la visualizzazione degli elementi LABEL usati per i campi modulo, l’evidenziazione delle tabelle e della loro struttura interna, la linearizzazione dei contenuti delle tabelle, la segnalazione di DIV, elenchi e altri elementi strutturali presenti nel codice.

Il menu Strumenti offre, oltre al collegamento a una serie di valutatori automatici dell’accessibilità, tra i quali il già esaminato WebXACT e l’italiano Torquemada collegamento esterno, anche alcune simulazioni visive molto interessanti, come per esempio la visualizzazione della pagina da parte di un malato di retinopatia diabetica (Figura 22.16).

Figura 22.16. La visione di una pagina web da parte di un malato di retinopatia diabetica, simulata tramite un comando del menu Struttura.

Il menu Informazioni meta fornisce informazioni di vario tipo sul documento in generale. Per esempio il tipo di DTD utilizzato, peso e tempo di caricamento della pagina considerando diverse velocità di connessione (Figura 22.17), il contenuto degli elementi META presenti nel codice, l’elenco dei link, degli script e degli eventuali oggetti di programmazione incorporati nel documento.

Figura 22.17. I contenuti del menu Informazioni meta e la finestra di dialogo generata dall’opzione Peso/Velocità della pagina.

Il menu Codice permette non solo di visualizzare il codice di marcatura dell’intero documento o di sue porzioni, ma anche di esaminare il codice generato da eventuali script, ovvero l’albero del DOM: una funzione utile, quest’ultima, per controllare la conformità al primo dei ventidue requisiti tecnici della legge italiana sull’accessibilità.

[Inizio approfondimento] Il requisito 1 della legge 4/2004 e le grammatiche formali

Ricordiamo che il requisito 1 della legge 4/2004 richiede la correttezza formale di qualsiasi codice associato a un documento, purché scritto in un linguaggio per il quale esiste una grammatica formale pubblicata. Il linguaggio JavaScript appartiene a tale categoria, essendo la sua definizione formale definita nelle Specifiche ECMA Script. Si veda il Capitolo 11 per maggiori informazioni su JavaScript, il Capitolo 21 per un’analisi del requisito 1 e il glossario online per il concetto di grammatica formale. [Fine approfondimento]

Inizio pagina

Salta inserzione pubblicitaria

Molto utile è anche la funzione del menu Codice che permette di porre in evidenza nella pagina gli eventuali elementi deprecati in essa presenti (Figura 22.18).

Figura 22.18. Un frammento di pagina web contenente una serie di elementi deprecati FONT, resi visibili tramite un comando del menu Codice.

Il menu Opzioni IE permette di attivare e disattivare selettivamente le immagini, gli script, i CSS, le funzioni ActiveX, oltre che di regolare la dimensione dei caratteri secondo il classico menu di Internet Explorer suddiviso in cinque passi (da “Molto grande” a “Molto piccolo”).

Il menu Risorse contiene una nutrita serie di collegamenti alle principali fonti di informazioni sull’accessibilità disponibili sul Web. In particolare, contiene i collegamenti diretti alle linee guida W3C, utili per chiarire eventuali dubbi sorti nel corso del lavoro di valutazione.

L’ultimo comando della barra è un’icona con la classica lente d’ingrandimento, che dà accesso a funzioni di ridimensionamento proporzionale della pagina, in una gamma che va dal 25% della grandezza base fino al 600%. Ridimensionamenti del 200% permettono di simulare l’esperienza di navigazione di un ipovedente, alle prese con la necessità di trovare un compromesso tra il bisogno di leggere chiaramente i testi e la difficoltà di usare lo scorrimento orizzontale, per recuperare i contenuti che, ingrandendo la pagina, finiscono fuori dalla finestra visibile (ecco una prova empirica dell’utilità di usare un’impaginazione liquida).

Informazioni più dettagliate sulle funzioni di ciascun comando della barra sono disponibili, infine, sul sito di Webaccessibile.org collegamento esterno.

Passando al mondo di Firefox, arricchito da estensioni realizzate da una vasta comunità di sviluppatori, troviamo almeno tre barre dell’accessibilità degne di menzione, dotate di caratteristiche in parte simili a quelle della Web Accessibility Toolbar appena esaminata, ma anche di funzioni peculiari, che allargano la gamma di valutazioni e test che è possibile svolgere su una pagina web.

Le tre barre sono, seguendo l’ordine dall’alto in basso di Figura 22.19:





Figura 22.19. Tre barre dell’accessibilità per Firefox: dall’alto, Web Developer 1.1.4, Mozilla Accessibility Extension v1.0, Accessibar 0.7.4.

Non è il caso di analizzare dettagliatamente tutte le funzioni delle tre barre, avendo già dedicato molto spazio alla descrizione delle funzioni della Web Accessibility Toolbar installata su Internet Explorer. Ci limiteremo perciò a indicare solo alcune caratteristiche salienti.

Una funzione interessante della barra Web Developer si trova nel menu Information. Tra le numerosissime opzioni presenti, il comando Display DIV order rende visibile, come una griglia sovrapposta ai contenuti, la struttura degli elementi DIV sulla quale è costruita la pagina. Il comando è utile soprattutto nei siti la cui gabbia grafica è gestita con DIV e CSS invece che con tabelle d’impaginazione.

Visualizzando la trama di DIV che regge l’impaginazione, il valutatore può rendersi conto della qualità del lavoro di strutturazione dei contenuti fatto da chi ha realizzato la pagina. Infatti, non basta eliminare le tabelle e passare ai DIV per essere sicuri di aver creato una struttura razionale e ben fatta. Le Figure 22.20 e 22.21 mettono a confronto due siti costruiti appunto su una gabbia di DIV, di cui il primo soffre della cosiddetta “divite”, cioè un eccesso di DIV, a cui corrisponde di solito un codice di marcatura molto complesso e poco gestibile; il secondo, invece, è un sito dedicato specificamente all’accessibilità e mostra una struttura di DIV molto più sobria e funzionale.

Figura 22.20. Un sito affetto da “divite”: la home page contiene in totale ben 112 DIV, ma il numero dei blocchi di contenuto effettivi è sensibilmente inferiore. La griglia dei DIV e il loro ordine sono resi visibili dal comando Display DIV order della barra Web Developer.

Figura 22.21. Un sito con un rapporto equilibrato tra DIV e blocchi di contenuto. A un basso numero di DIV annidati corrisponde in genere una struttura del codice semplice e facile da gestire.

Sempre nel menu Information, è presente il comando View Document Outline, che mostra la gerarchia di titoli del documento corrente in modo simile a quanto fa l’analoga funzione della Web Accessibility Toolbar di Internet Explorer, ma in più evidenzia i salti tra i livelli d’intestazione (Figura 22.22), fornendo così un rapido strumento visuale per identificare i punti che necessitano di correzione. Il riferimento è alle Tecniche HTML per il punto di controllo 3.5 delle WCAG 1.0, che richiedono di usare gli elementi H1-H6 per creare una corretta gerarchia di contenuti, evitando salti di livello (per maggiori dettagli, si veda il commento al punto di controllo 3.5 nel Capitolo 6).

Figura 22.22. Le voci “[Missing Heading]” segnalano i livelli d’intestazione mancanti.

Inizio pagina

Nel menu Miscellaneus della barra Web Developer è presente un’altra utile funzione, peraltro nativamente disponibile nel browser Opera: si tratta dell’opzione Small Screen Rendering, che genera la linearizzazione dei contenuti, adattandoli a una larghezza di 260 pixel, simulando così la visualizzazione tipica di un computer palmare. Tramite questo comando, il valutatore può rendersi conto dell’ordine di navigazione dei contenuti: se il testo principale è preceduto da una lunga serie di link e di contenuti accessori, l’usabilità per gli utenti di palmari, e anche per gli utenti di screen reader e in generale per chi non può usare il mouse, è scarsa, soprattutto se mancano link di salto e tasti di accesso rapido (Figura 22.23). Il sito de La Stampa, mostrato nell’immagine, ha tuttavia un sito parallelo accessibile, riservato agli utenti registrati).

Figura 22.23. La vista linearizzata del sito La Stampa.it (a destra nell’immagine), generata con la funzione Small Screen Rendering della barra Web Developer, a confronto con la vista multicolonna ottenuta in un normale browser grafico (a sinistra). I titoli principali non sono visibili nella vista linearizzata.

Un’icona posta all’estremità destra della barra Web Developer avverte il valutatore se il documento esaminato è caricato nel browser secondo la modalità standard (in questo caso l’icona è un segno di spunta verde) oppure nel cosiddetto Quirks mode (l’icona è allora una “X” rossa). Si veda il Capitolo 6 per informazioni sulle differenze tra modalità standard e Quirks mode.

Passando alla Mozilla Accessibility Extension, la seconda delle tre barre dell’accessibilità che abbiamo segnalato per Firefox, notiamo che nel menu Navigation è presente una funzione utile per la valutazione della coerenza dei meccanismi di navigazione di un sito (punto di controllo 13.4 delle WCAG 1.0. Si veda il relativo commento nel Capitolo 18).

Si tratta del comando Menu and Navigation Bars, scegliendo il quale si apre una finestra di dialogo divisa in due parti (Figura 22.24). La parte superiore contiene l’elenco di tutti i menu e le barre di navigazione che il software rileva dall’esame automatico della pagina web caricata nel browser. Selezionando una voce dall’elenco, viene evidenziato sulla pagina il relativo menu di navigazione, mentre nella parte inferiore della finestra vengono mostrati i link che compongono il menu, completi di testo visibile e destinazione del collegamento (visitabile mediante il pulsante Go to URL, posto al fondo della finestra). Un esame accurato del numero, dei contenuti e della sequenza delle barre di navigazione, non solo in una singola pagina, ma nell’intero sito, è indispensabile per decidere se il punto di controllo 13.4 è da ritenersi superato oppure no.

Figura 22.24. Il comando Menu and Navigation Bars del menu Navigation apre la finestra di dialogo mostrata nell’immagine, che fornisce un valido aiuto nella valutazione della coerenza dei meccanismi di navigazione di un sito.

Il menu Text Equivalents contiene tra gli altri il comando List of Images, che dà accesso a una finestra di dialogo che mostra sinotticamente i valori di alt e di longdesc di tutte le immagini presenti in un documento (Figura 22.25). Permette di identificare rapidamente le immagini prive di testo alternativo e di controllare la correttezza dei testi alternativi già inseriti.

Figura 22.25. L’elenco dei valori di alt e di longdesc usati nel documento caricato nel browser, mostrato tramite il comando List of Images del menu Text Equivalents della barra Mozilla Accessibility Extension.

Un’altra funzione interessante di questa barra è nel menu Scripting. La voce List of Events apre la finestra mostrata in Figura 22.26, che contiene nella parte superiore l’elenco degli elementi a cui sono associati degli eventi e, nella parte inferiore, l’elenco degli eventi relativo all’elemento selezionato. L’esame di un documento tramite la finestra List of Events permette di scoprire, molto più rapidamente di quanto consenta l’esame diretto del codice di marcatura, quali elementi sono associati a eventi e, soprattutto, se gli eventi utilizzati corrispondono alle richieste delle WCAG 1.0 per quanto riguarda i criteri di indipendenza dal dispositivo (il riferimento è ai punti di controllo 6.4 e 9.3).

Figura 22.26. La finestra List of Events permette di capire rapidamente se gli eventi utilizzati in un documento corrispondono ai criteri di indipendenza dal dispositivo richiesti dagli standard di accessibilità.

Nello stesso menu Scripting, il comando Disable Mouse Events permette di verificare manualmente se la pagina è effettivamente utilizzabile in assenza degli eventi indotti da operazioni del mouse.

Nel menu Style, sono disponibili due comandi, High Contrast View 1 e 2, che modificano l’impaginazione del documento, ingrandendo notevolmente i caratteri e impostando delle combinazioni di colori ad alto contrasto (il primo, bianco su sfondo nero, il secondo nero su sfondo bianco). L’esecuzione di questi due comandi consente al valutatore di verificare la resistenza del layout di pagina alle condizioni di navigazione tipiche dell’ipovisione (Figura 22.27). Ricordiamo che il requisito tecnico numero 12 della legge italiana sull’accessibilità richiede espressamente che la modifica delle condizioni di visualizzazione del documento non crei sovrapposizioni di contenuti e perdita d’informazioni.

Figura 22.27. In basso a destra la home page del sito Microsoft, vista dopo l’applicazione del comando High Contrast View 2 della Mozilla Accessibility Extension (in alto a sinistra,la vista predefinita della pagina).

Accessibar 0.7.4, l’ultima delle tre barre che abbiamo preso in esame, dispone di una serie di comandi interattivi, che, più che servire per una valutazione diretta di accessibilità, servono come simulazioni a uso dello sviluppatore, utili per definire le condizioni di migliore leggibilità dei contenuti. La barra permette, infatti, di modificare dinamicamente il colore del testo e dello sfondo di pagina, di cambiare il tipo di carattere, di ingrandire e rimpicciolire il testo e di aumentare e diminuire dinamicamente l’interlinea (cioè lo spazio verticale tra due righe consecutive).

La dotazione di comandi della barra è completata da un lettore vocale che, previa installazione del necessario supporto text-to-speech (cioè di una voce sintetica), è in grado di leggere ad alta voce – per ora, però, solo in inglese – l’intero contenuto testuale del documento caricato nel browser. L’uso di questa funzione fornisce un metodo relativamente rapido per controllare se l’ordine di lettura dei contenuti è significativo per un utente di screen reader.

Figura 22.28. La finestra per impostare le caratteristiche della voce sintetica inclusa nelle funzioni di Accessibar versione 0.7.4.

[Inizio approfondimento] Fire Vox e Fangs

La medesima prova può essere effettuata con Fire Vox collegamento esterno, un’estensione gratuita di Firefox di cui abbiamo già parlato alla fine del Capitolo 11.

Un metodo ancora più rapido per verificare l’ordine di lettura consiste nell’utilizzare Fangs, un’altra estensione di Firefox, le cui funzioni sono descritte alla pagina http://www.standards-schmandards.com/projects/fangs collegamento esterno (che contiene anche il collegamento per l’installazione).

Figura 22.29. La simulazione di Fangs per la home page del sito del Governo italiano.

In breve, Fangs è un emulatore di screen reader, che crea una rappresentazione testuale dei contenuti della pagina, analoga all’output vocale di uno screen reader (Figura 22.29): oltre al testo visibile sono riportate le informazioni sui livelli di intestazione, sui tasti di accesso rapido, sui testi alternativi, sulla punteggiatura ecc. È come “ascoltare” visivamente un lettore vocale. Il limite di Fangs è che può essere utilizzato per verifiche di accessibilità solo da utenti vedenti, ma, per questi ultimi, rappresenta un sistema di valutazione sicuramente più comodo di uno screen reader come JAWS, un’applicazione complessa e sofisticata, la cui curva di apprendimento è di conseguenza elevata. [Fine approfondimento]

Inizio pagina

Esito della validazione e loghi di conformità

In base a quanto stabilito dal paragrafo 5 Conformance collegamento esterno delle WCAG 1.0, sono possibili tre gradi di conformità a queste linee guida:

  1. Conformità di Livello “A”. Indica che sono stati soddisfatti tutti i punti di controllo di priorità 1;
  2. Conformità di Livello “Doppia-A”. Indica che sono stati soddisfatti tutti i punti di controllo di priorità 1 e di priorità 2;
  3. Conformità di Livello “Tripla-A”. Indica che sono stati soddisfatti tutti i punti di controllo di priorità 1, 2 e 3.

Lo scopo principale di un processo di validazione basato sulle WCAG 1.0 è stabilire, appunto, qual è il livello di conformità che la pagina web o il sito valutati raggiungono. L’esito finale di tutto il lavoro di valutazione dovrebbe essere una dichiarazione di accessibilità, in cui i responsabili del sito valutato rendono pubbliche una serie di informazioni sulla validazione, tra le quali sono particolarmente importanti, oltre all’ovvia indicazione del livello di accessibilità raggiunto, anche:

Il documento WAI intitolato Template for Accessibility Evaluation Reports collegamento esterno contiene un modello di resoconto molto dettagliato, che indica una lunga serie di informazioni che i responsabili dell’accessibilità dovrebbero pubblicare, al termine di una procedura di validazione, per rendere realmente attendibile la dichiarazione del livello di accessibilità raggiunto.

Tuttavia è molto raro che i siti che si dichiarano accessibili in base alle WCAG 1.0 pubblichino un resoconto che si avvicini anche lontanamente al livello di dettaglio richiesto dal modello di dichiarazione che si trova nel documento WAI citato. In genere ci si limita – e non è una buona cosa – all’elemento che dà maggiore visibilità agli occhi degli utenti: il cosiddetto “bollino” di accessibilità (Figura 22.30), eventualmente collegato alla pagina del sottosito WAI che spiega il significato dei loghi di conformità alle WCAG 1.0 e i limiti del loro utilizzo.

Figura 22.30. I tre loghi (o “bollini”) di conformità ai livelli A, doppia-A e tripla-A delle WCAG 1.0.

La pagina in questione si intitola W3C Web Content Accessibility Guidelines 1.0 Conformance Logos collegamento esterno (“Loghi di conformità alle Web Content Accessibility Guidelines 1.0 del W3C”). Spiega chiaramente che l’esposizione di un “bollino” di conformità alle WCAG 1.0 va riferito solo alla pagina web in cui appare (a meno che non sia esplicitamente dichiarata un’estensione maggiore) e, soprattutto, che non si tratta di un certificato ufficiale di accessibilità riconosciuto dal WAI/W3C, ma di una semplice pretesa (claim) di conformità alle linee guida WCAG, avanzata dal soggetto che espone il logo.

Per maggiore chiarezza, riportiamo in traduzione italiana il contenuto della sezione Responsibility for accuracy of claims collegamento esterno del documento WAI citato:

I fornitori di contenuti sono i soli responsabili per l’uso di questi loghi. Prima di usare tali loghi come parti di una dichiarazione di conformità, si raccomanda che i fornitori abbiano familiarità con le Web Content Accessibility Guidelines 1.0 e usino una molteplicità di metodi di revisione, per garantire che ogni pagina che espone questo logo soddisfi il livello di conformità dichiarato. I fornitori dovrebbero inoltre garantire che chiunque gestisca o aggiorni il sito abbia familiarità con l’uso del logo e che, nel caso non sia più certo se la pagina soddisfi ancora il livello di conformità specificato, esegua una nuova revisione oppure rimuova il logo dalla pagina.

Dovrebbe essere chiaro, a questo punto, che la sola esposizione di un bollino di conformità alle WCAG 1.0 non basta a garantire che la pagina web che lo espone, e più ancora il sito a cui la pagina appartiene, soddisfino realmente i requisiti di accessibilità di cui quel logo rappresenta il superamento.

Giusto per dare un’idea della complessità del modello di dichiarazione di conformità previsto dal WAI, riportiamo di seguito l’elenco schematico delle informazioni che una dichiarazione di accessibilità conforme a quel modello dovrebbe contenere:

A onor del vero, va precisato che il paragrafo 5 Conformance collegamento esterno delle WCAG 1.0 prevede una dichiarazione di conformità estremamente stringata, basata sul seguente modello:

Questa pagina è conforme al livello Doppia-A delle Web Content Accessibility Guidelines 1.0 del W3C, disponibili presso http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505.

In alternativa a tale dichiarazione, è previsto l’uso di uno dei tre loghi di conformità descritti a inizio paragrafo e mostrati in Figura 22.30.

Insomma, le WCAG 1.0 non richiedono un resoconto complesso e articolato della procedura di validazione com’è quello presentato nel documento WAI Template for Accessibility Evaluation Reports. È tuttavia evidente che, tra la mera esposizione di un bollino e una ricca e articolata dichiarazione di accessibilità, che renda conto passo per passo delle ragioni che hanno portato a dichiarare il raggiungimento di un dato livello di conformità alle WCAG 1.0, è di gran lunga preferibile la seconda soluzione: si tratta di un segno di professionalità, oltre che di una forma di rispetto e di garanzia per gli utenti.

Se proprio non è possibile rendere pubbliche tutte le informazioni indicate nel modello proposto dal WAI, si cerchi almeno di specificare la gamma di pagine per le quali la dichiarazione di conformità è da ritenersi valida, i punti di controllo che sono stati superati, la data in cui è stata eseguita la valutazione, l’indirizzo e-mail di un responsabile per l’accessibilità.

Inizio pagina

La validazione secondo la legge 4/2004

I criteri con cui viene stabilito il livello di accessibilità di un sito web secondo la legge italiana 4/2004, di cui abbiamo ampiamente trattato nel Capitolo 21, sono definiti nel decreto attuativo dell’8 luglio 2005. In particolare, il comma 2 dell’articolo 2 del decreto Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici collegamento esterno dichiara:

Il primo livello di accessibilità dei siti Web è accertato previo esito positivo della verifica tecnica che riscontra la conformità delle pagine dei medesimi siti ai requisiti tecnici elencati nell’allegato A, applicando la metodologia ivi indicata.

E il comma 2 dell’articolo 5 aggiunge:

Nella verifica tecnica l’esperto tecnico, applicando la metodologia di cui all’allegato A, paragrafo 2:

  1. svolge le attività previste alla lettera a) del medesimo paragrafo 2 su tutte le pagine del sito;
  2. svolge le attività previste alle lettere b), c) e d) del medesimo paragrafo 2 sulla home page, su tutte le pagine del sito direttamente raggiungibili dalla home page, su tutte le tipologie di pagine che presentano form e di pagine di risposta, nonché su un campione statistico di pagine, non rientranti in quelle esaminate precedentemente, pari al 5% delle stesse;
  3. redige il rapporto di cui alla lettera e) del medesimo paragrafo 2.

Nell’articolo 1 del decreto, la verifica tecnica è definita una valutazione condotta da esperti, anche con strumenti informatici, sulla base di parametri tecnici, mentre l’esperto tecnico è definito un soggetto esperto in tecnologie Web e problematiche dell’accessibilità.

La verifica tecnica

Se questi sono gli obblighi e le definizioni che il decreto stabilisce per il conseguimento del primo livello di accessibilità, occorre ora dare un contenuto alle lettere a), b), c), d) ed e) dell’allegato A del decreto, a cui fa riferimento il comma 2 dell’articolo 5. Dobbiamo sapere, in altre parole, secondo quali modalità deve svolgersi l’attività di valutazione e come deve essere redatto il rapporto che contiene le conclusioni sul lavoro svolto.

La risposta a tali domande è contenuta nel paragrafo 2 dell’allegato A del Decreto Ministeriale 8 luglio 2005 Verifica tecnica e requisiti tecnici di accessibilità delle applicazioni basate su tecnologie internet collegamento esterno.

Ne riportiamo di seguito il testo, intervallandolo con qualche spiegazione, resa necessaria da alcuni passaggi in cui l’uso del “burocratese” rischia di oscurare il senso delle frasi:

La verifica tecnica si articola nelle seguenti attività:

a) riscontro, con sistemi di validazione automatica, della rispondenza alla sua definizione formale del linguaggio a marcatori utilizzato;

Vuole dire che bisogna passare le pagine web oggetto di valutazione all’analisi di un validatore automatico (per esempio, http://validator.w3.org/ collegamento esterno) e che ogni errore segnalato deve essere corretto, in modo da ottenere documenti a zero errori di codice HTML o XHTML. Infatti, un documento senza errori segnalati dal validatore automatico risponde alla “definizione formale del linguaggio a marcatori utilizzato”, cioè rispetta la DTD che è stata dichiarata (nei limiti in cui il validatore è in grado di verificare tale corrispondenza).

b) verifica dell’esperto tecnico sul corretto utilizzo semantico degli elementi e degli attributi secondo le specifiche del linguaggio a marcatori impiegato, anche mediante l’uso di strumenti semiautomatici di valutazione allo scopo di evidenziare problemi non riscontrabili dalle verifiche automatiche;

Vuole dire che l’esperto tecnico che svolge la valutazione deve controllare che elementi e attributi siano utilizzati secondo il significato che viene loro attribuito dalle specifiche di riferimento. In altre parole, se il documento esaminato è in HTML e l’elemento BLOCKQUOTE è usato per generare un effetto di rientro del testo invece che per marcare una citazione, si tratta di un errore da segnalare, perché un tale uso non corrisponde alla semantica dell’elemento BLOCKQUOTE, così come è descritta dalle specifiche HTML (ovvero non corrisponde allo scopo dell’elemento, al suo significato, che è quello di marcare blocchi di testo citato da altre fonti).

Errori di questo tipo possono essere notati e corretti solo da un essere umano, non da uno strumento automatico: l’analisi dei validatori automatici si basa, infatti, sul rispetto delle regole formali definite dalle DTD, che nulla possono dire sul significato dei testi racchiusi da elementi e attributi.

È un po’ ambiguo, perciò, a nostro avviso, collegare – come fa il testo del punto b) – l’attività di verifica della semantica all’uso di strumenti semiautomatici (“anche mediante l’uso di strumenti semiautomatici di valutazione”): per il momento nessun software, per quanto perfezionato, è in grado di aiutare realmente un essere umano a capire se elementi e attributi sono stati usati in modo corrispondente al significato definito dalle specifiche. Al massimo, un software potrà elencare le occorrenze di ogni singolo elemento e attributo all’interno di un documento e segnalare i potenziali problemi di accessibilità che è saggio controllare in base agli elementi e agli attributi che compaiono nel codice: funzione senz’altro utilissima, ma che lascia completamente sulle spalle del valutatore umano l’onere di verificare l’aspetto semantico (per esempio, se è appropriato l’uso di alt="" in relazione a un elemento IMG).

Riassumendo: 1) viene richiesto che un esperto tecnico controlli la semantica di elementi e attributi; 2) si consiglia, come ausilio per l’esperto tecnico, l’uso di software che analizzano il codice di marcatura e identificano – senza essere però in grado di valutarli direttamente – una serie di potenziali problemi di accessibilità che hanno a che fare con la semantica invece che con la sintassi del codice (WebXACT, per citarne uno, appartiene a questa categoria di strumenti software).

c) esame della pagina con varie versioni di diversi browser grafici in vari sistemi operativi allo scopo di verificare che:

  1. il contenuto informativo e le funzionalità presenti in una pagina siano gli stessi nei vari browser;
  2. la presentazione della pagina sia simile nei browser che supportano le tecnologie indicate al requisito n. 1 di cui al paragrafo 4 del presente allegato;
  3. il contenuto informativo e le funzionalità della pagina siano ancora fruibili in caso di disattivazione del caricamento delle immagini;
  4. i contenuti informativi di eventuali file audio siano fruibili anche in forma testuale;
  5. i contenuti della pagina siano fruibili in caso di utilizzo delle funzioni previste dai browser per definire la grandezza dei caratteri;
  6. la pagina sia navigabile con il solo uso della tastiera e l’impiego di una normale abilità;
  7. i contenuti e le funzionalità della pagina siano ancora fruibili, anche in modalità diverse, in caso di disattivazione di fogli di stile, script e applet e altri oggetti di programmazione;
  8. i contenuti e le funzionalità continuino a essere disponibili con un browser testuale e i medesimi contenuti mantengano il proprio significato d’insieme e la corretta struttura semantica;

Il requisito 1 parla di “tecnologie definite da grammatiche formali pubblicate nelle versioni più recenti disponibili quando sono supportate dai programmi utente” (si veda il Capitolo 21). In parole più semplici, il punto 2) richiede che una pagina HTML o XHTML si veda in modo simile su browser grafici differenti.

Gli otto tipi di controlli descritti al punto c) della metodologia hanno strette analogie con le verifiche richieste ai punti 4-6 dell’appendice A delle WCAG 1.0. È la parte del processo di validazione che corrisponde al controllo manuale dell’accessibilità dei contenuti, effettuato nelle più diverse condizioni di fruizione. Il ridimensionamento dei caratteri, la disabilitazione dei fogli di stile, delle immagini, degli script e degli oggetti di programmazione, l’uso della tastiera al posto del mouse sono tutte condizioni che non devono impedire l’utilizzo delle informazioni e delle funzionalità contenute nelle pagine web analizzate. In breve, l’esperto tecnico deve verificare che i contenuti siano indipendenti sia dal dispositivo di input (mouse o tastiera) sia dal dispositivo di output (monitor o screen reader).

Il limite della procedura descritta al punto c) dell’allegato A è che rimangono indeterminati i software che devono essere utilizzati nella verifica. Si parla, infatti, di “varie versioni di diversi browser grafici in vari sistemi operativi” e di “browser che supportano le tecnologie indicate al requisito n. 1”, ma non sono indicati esplicitamente né i sistemi operativi né i singoli browser né le loro versioni.

Come già abbiamo avuto modo di rilevare nel Capitolo 21, lasciare la definizione delle condizioni di applicazione o di verifica di una legge al buon senso di chi deve occuparsene non ci sembra una buona cosa. Se un valutatore, per esempio, si è limitato a usare per i suoi test Internet Explorer 5 e 5.5 su Windows 2000 e Safari 1 e 2 su Mac OS X, magari perché aveva poco tempo a disposizione e si trovava a lavorare in uno studio di fortuna, è lecito dire che abbia eseguito la verifica manuale in modo conforme a quanto prescrive il punto c) dell’allegato A? Secondo noi sì, perché l’unica cosa certa è che “varie versioni di diversi browser grafici in vari sistemi operativi” significa più di un browser, più di una versione, più di un sistema operativo. Il fatto, però, che siano rimasti esclusi dalla verifica i sistemi operativi Linux e Windows XP nonché le versioni più recenti di Internet Explorer (la 6 e la 7) ci dice che non si è trattato di una verifica completa e del tutto attendibile.

Insomma, ci sarebbe piaciuto che il decreto di attuazione della legge 4/2004 avesse elencato una ragionevole gamma di browser, versioni e sistemi operativi da utilizzare per le verifiche manuali. Considerando che la legge prevede il periodico aggiornamento del decreto, l’elenco di sistemi operativi e programmi utente da utilizzare per la verifica manuale avrebbe potuto essere aggiornato insieme con il decreto, evitando così il rischio di vincolare i test ad applicazioni e piattaforme obsolete e non più utilizzabili.

Tanto per citare un esempio a sostegno della nostra tesi, le linee guida per l’accessibilità dei siti del governo britannico, risalenti all’ormai lontano 2002, elencavano un’ampia serie di browser collegamento esterno – certo, oggi del tutto obsoleti – che potevano essere utilizzati per la verifica manuale dell’accessibilità.

[Inizio approfondimento] Browsercam

Per chi desidera svolgere una verifica manuale veramente completa, ma non dispone di una gamma di sistemi operativi, browser e versioni adeguata a coprire tutte le possibili combinazioni di software realmente utilizzate dagli utenti, è disponibile un’alternativa di test in remoto. Si tratta del sito Browsercam collegamento esterno. Mediante una registrazione a pagamento (ma con possibilità di una prova gratuita di 24 ore), si ha accesso a una vasta gamma di sistemi operativi, browser e loro versioni, che possono essere controllati in remoto dall’utente. È possibile così verificare la visualizzazione di una data pagina web sui più diversi browser, con la possibilità di catturare le schermate delle prove svolte, per successivi confronti. Alla pagina http://www.browsercam.com/Features.aspx collegamento esterno è presente l’elenco dei dispositivi governabili in remoto, che comprende anche una nutrita serie di browser per palmari. [Fine approfondimento]

d) verifica delle differenze di luminosità e di colore tra il testo e lo sfondo secondo i seguenti algoritmi:

  1. differenza di luminosità: calcolo della luminosità dei colori di testo e di sfondo con la formula: ((Rosso × 299) + (Verde × 587) + (Blu × 114)) / 1000, in cui Rosso, Verde e Blu sono i valori decimali dei colori; il risultato deve essere non inferiore a 125.
  2. differenza di colore: calcolo della differenza di colore con la formula [Max(Rosso1, Rosso2) - Min(Rosso1, Rosso2)] + [Max(Verde1, Verde2) – Min(Verde1, Verde2)] + [Max(Blu1, Blu2) – Min(Blu1, Blu2)], in cui Rosso, Verde e Blu sono i valori decimali dei colori e Max e Min il valore massimo e minimo tra i due presi in considerazione; il risultato deve essere non inferiore a 500;

Si tratta delle due medesime formule già descritte alla fine del Capitolo 5.

e) redazione di un rapporto nel quale l’esperto tecnico indica la conformità, la non conformità o l’eventuale non applicabilità di ogni singolo requisito della pagina esaminata.

Esiste un modello prestampato per la redazione del rapporto finale collegamento esterno dell’esperto tecnico, che può essere scaricato dal sito del CNIPA. Il modello è suddiviso in cinque parti, che comprendono rispettivamente:

  1. le informazioni generali sull’ente che effettua la dichiarazione (nome dell’ente, responsabile per l’accessibilità, indirizzo del sito valutato, data di conclusione della valutazione);
  2. l’elenco dei browser grafici, delle relative versioni e dei sistemi operativi che sono stati utilizzati per le verifiche richieste dalla metodologia di valutazione;
  3. l’elenco degli strumenti automatici e semiautomatici utilizzati nel corso dell’attività di valutazione;
  4. la dichiarazione di conformità ai ventidue requisiti tecnici definiti al paragrafo 4 dell’allegato A, costruita come una tabella nella quale a ciascun requisito sono associati una valutazione (“applicato”, “non applicato”, “non pertinente”) e un’eventuale nota di chiarimento;
  5. una tabella suddivisa in nove punti, che riporta i singoli passi della verifica manuale, per ciascuno dei quali deve essere dichiarato il superamento, il fallimento o la non applicabilità, con eventuali note di chiarimento.

Riportiamo a titolo esemplificativo alcune tabelle tratte dai rapporti conclusivi di accessibilità presentati da alcuni degli enti che sono inclusi nell’elenco ufficiale di siti conformi alla legge 4/2004 collegamento esterno, tenuto dal CNIPA. Presentiamo questi dati – è bene precisarlo – per il loro valore di testimonianza sull’uso reale, non perché il lettore li consideri modelli ideali di riferimento nella compilazione del rapporto.

Tabella 22.1 Elenco dei brower grafici usati per la verifica di accessibilità del sito dell’Istituto Superiore di Sanità collegamento esterno
Browser Versione Ambiente operativo
Safari 2.0.4 (419.3) Mac OS X 10.4.8
Firefox 2.0.0.1 Mac OS X 10.4.8
Opera 9.02.3512 Mac OS X 10.4.8
Firefox 2.0.0.1 Windows XP Pro SP2
Internet Explorer 6.x, 7.x Windows XP Pro SP2
Opera 9.02 build 8585 Windows XP Pro SP2
Firefox Mozilla 5.0 (x11;U;Linux x86_64;it;rv:1.8.1) Linux (Kubuntu i686)
Gecko/Firefox 20060601/2.0 (Ubuntu-edgy) Linux (Kubuntu i686)
Konqueror 3.5.5 Linux (Kubuntu i686)
Tabella 22.2 Elenco degli strumenti automatici e semiautomatici usati nella valutazione di accessibilità del sito della Provincia di Milano collegamento esterno
Nome Versione Ambiente operativo
W3C Markup Validation Service 0.7.4 Online
Cynthia Says™ Web Content Accessibility Report Online
WebXACT Online
W3C CSS Validator 2.0 Online
AIS - Accessibility Toolbar 1.2 Windows
Mozilla Firefox Web Developer Toolbar 1.0.2 Windows
Colour Contrast Analyser 1.1 Windows
Vischeck Online
Htmlvalidator tidy 0.3.1 Windows
WSOP 2.0 Windows
Browsercam Online
Tabella 22.3 Conformità ai ventidue requisiti tecnici del sito della Camera di Commercio di Ferrara collegamento esterno
Requisito Conforme (Si/No/N.A.) Annotazioni
1 Tutte le pagine realizzate sono valide secondo la DTD di XHTML 1.0 Strict.
2 N.A. Lo strumento non usa, né permette l’uso di Frame o IFrame.
3 Tutte le immagini significative hanno una descrizione alternativa e/o un testo equivalente, anche quelle incluse nei contenuti tramite l’editor integrato disponibile ai redattori.
4 Nessun contenuto presentato è direttamente collegato al particolare colore utilizzato per la sua presentazione all’interno della pagina.
5 Il sito non presenta nessun oggetto lampeggiante o in movimento
6 Tutti i testi e i colori di sfondo rispettano le formule matematiche di contrasto e differenze di colori richieste dalle WCAG 1.0 del W3C.
7 N.A. Nel sito non sono presenti mappe immagine.
8 N.A. Nel sito non sono presenti mappe immagine.
9 Le tabelle dati presenti utilizzano gli elementi e gli attributi previsti dalla DTD per descrivere i contenuti e identificare intestazioni di righe e colonne.
10 Per le tabelle dati che presentano due o più livelli logici di intestazione di righe o colonne sono stati utilizzati gli elementi e gli attributi dalla DTD
11 La presentazione dei contenuti è controllata da fogli stile. I contenuti restano comunque accessibili anche nel caso in cui l’utente abbia disabilitato l’uso dei CSS, o per accessi linearizzati alle informazioni della pagina.
12 La presentazione dei contenuti si adatta alle dimensioni della finestra del browser senza sovrapposizione degli oggetti e perdita di informazione, da una risoluzione minima di 800×600.
13 L’unica tabella presente a scopo di impaginazione è quella che gestisce le colonne laterali e il corpo centrale della pagina. Il contenuto di questa è comprensibile anche effettuando la linearizzazione della pagina ed eliminando i fogli di stile.
14 I form presenti hanno sempre descrizioni ed etichette associate ai vari campi.
15 Disabilitando Java e JavaScript tutte le funzionalità disponibili agli utenti restano integre. Unica eccezione è la funzionalità di livesearch, comunque disponibile solo come scorciatoia della ricerca, che è sempre accessibile.
16 Le funzionalità degli script sono indipendenti dai dispositivi di input.
17 Non sono presenti informazioni veicolate da oggetti di programmazione quali script.
18 N.A. Il sito non presenta allo stato attuale filmati e presentazioni multimediali.
19 Per quanto possibile si è cercato di descrivere adeguatamente ogni link in modo tale da renderne esplicita la destinazione. Il portale offre sempre una serie di link posti prima di ogni altro contenuto, che permettono di saltare immediatamente a varie zone della pagina, evitando le sezioni ripetitive di testo comune a ogni pagina.
20 N.A. Non sono presenti servizi nei quali sia previsto eseguire particolari azioni in un determinato intervallo di tempo.
21 I collegamenti sono tutti selezionabili e attivabili da tastiera o sistemi di puntamento alternativi. Le distanze verticali e le spaziature orizzontali sono sempre garantite.
22 N.A. Il portale offre, allo stato attuale, solo pagine accessibili e non c’è bisogno di ricorrere a versioni alternative di pagine presenti.
Tabella 22.4 Esito dell’applicazione della metodologia di verifica manuale alle pagine del sito del Consiglio Nazionale dei Consumatori e degli Utenti (CNCU) collegamento esterno
Punto di controllo Sì/No/N.A. Annotazioni
a) Contenuto e funzionalità presenti nelle pagine del sito sono gli stessi nei vari browser? Il contenuto e le funzionalità del sito vengono riproposti in maniera analoga nei vari browser.
b) La presentazione delle pagine è simile in tutti i browser che supportano le tecnologie indicate al Requisito 1? La presentazione rimane invariata sui browser che supportano la DTD XHTML 1.0 Strict.
c) Disattivando il caricamento delle immagini, contenuto e funzionalità del sito sono ancora fruibili? In assenza di immagini il sito risulta navigabile e mantiene funzionalità e accesso al contenuto.
d) Disattivando il suono, i contenuti di eventuali file audio sono fruibili in altra forma? n.a. Non sono presenti file audio.
e) Utilizzando i controlli disponibili nei browser per definire la grandezza dei font, i contenuti delle pagine sono ancora fruibili? Il contenuto delle pagine del sito è fruibile anche ridimensionando i caratteri con l’ausilio dei controlli del browser.
f) Le pagine sono navigabili in modo comprensibile con il solo uso della tastiera? Sono presenti delle accesskey per la navigazione principale e tutto il documento è navigabile con la sola tastiera.
g) I contenuti e le funzionalità del sito sono ancora fruibili (anche in modo equivalente) quando si disabilitano fogli di stile, script e applet e oggetti? Il sito mantiene funzionalità e i contenuti sono fruibili anche in caso di disabilitazione dei fogli di stile e degli oggetti di programmazione.
h) Esaminando le pagine del sito con un browser testuale:
  • Contenuti e funzionalità sono disponibili (anche in modo equivalente) così come nei browser grafici?
  • I contenuti delle pagine mantengono il loro significato d’insieme e la loro struttura semantica?
Anche in modalità testuale contenuti e funzionalità mantengono un’equivalenza a quanto reso nei browser grafici; le pagine non perdono la struttura semantica e il significato d’insieme.
i) Le differenze di luminosità e di colore tra il testo e lo sfondo sono sufficienti, secondo gli algoritmi suggeriti dal W3C? La differenza di luminosità tra fondo e testo in primo piano è in linea con le specifiche W3C.

Inizio pagina

La verifica soggettiva

Il comma 4 dell’articolo 2 del decreto attuativo dell’8 luglio 2005 spiega:

Il secondo livello di accessibilità riguarda la qualità delle informazioni fornite e dei servizi erogati dal sito Web e si articola in primo, secondo e terzo livello di qualità; tali livelli di qualità sono accertati con la verifica soggettiva attraverso i criteri di valutazione di cui all’allegato B, applicando la metodologia ivi indicata.

Il comma 3 dell’articolo 5 del medesimo decreto aggiunge:

La verifica soggettiva consta delle attività, previste dalla metodologia di cui all’allegato B, svolte dall’esperto in fattori umani, dall’esperto di interazione con le persone disabili e dal gruppo di valutazione; il costo complessivo della verifica tiene anche conto dei tempi di utilizzo delle tecnologie assistive impiegate.

L’articolo 1 del decreto contiene le definizioni dei termini utilizzati nei due commi citati. Dalle definizioni apprendiamo che la verifica soggettiva è la “valutazione del livello di qualità dei servizi, già giudicati accessibili tramite la verifica tecnica, effettuata con l’intervento del destinatario, anche disabile, sulla base di considerazioni empiriche”.

L’esperto di fattori umani è invece un “soggetto in possesso di diploma di laurea, anche triennale, comprendente un anno di formazione in discipline ergonomiche, quali ergonomia dell’ambiente, ergonomia dell’hardware, ergonomia cognitiva, macroergonomia, che abbia svolto un tirocinio documentato di almeno un anno”; mentre l’esperto di interazione con persone disabili è un “soggetto in possesso di diploma di laurea, anche triennale, esperto di problematiche di comunicazione e di utilizzo delle tecnologie dell’informazione e della comunicazione, che abbia maturato un’esperienza professionale biennale nel settore”.

Infine, il gruppo di valutazione è un “gruppo di utenti, anche disabili, che svolgono compiti assegnati dall’esperto di fattori umani per l’effettuazione della verifica soggettiva”.

L’apposita metodologia, descritta nell’allegato B del decreto 8 luglio 2005 collegamento esterno, comprende due tipi di esame: la simulazione cognitiva svolta da un esperto di fattori umani e l’esecuzione di test con un gruppo di valutazione, costituito da “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 interessate ad accedere al sito”.

Abbiamo già descritto le fasi della verifica soggettiva nel corso del Capitolo 21, al quale rimandiamo per maggiori dettagli. Aggiungiamo qui che il controllo di qualità richiesto dalla verifica soggettiva, così come è definita nel decreto 8 luglio 2005, ha a che fare più con l’usabilità che con l’accessibilità e richiede, infatti, le competenze di un esperto in fattori umani per poter essere eseguita conformemente alle richieste della legge. Non è, quindi, materia strettamente attinente all’argomento del nostro libro, che si rivolge in primo luogo agli sviluppatori e cioè a quelli che l’articolo 1 del decreto definisce “esperti tecnici”.

Intendiamoci: i risultati di test di usabilità svolti con soggetti disabili sono senz’altro importantissimi ai fini della valutazione di accessibilità di un sito web (lo abbiamo accennato più volte, trattando della procedura di validazione delle WCAG 1.0), ma l’analisi della metodologia con cui vengono eseguiti tali test è al di là dei nostri scopi e, del resto, neppure l’allegato B del decreto attuativo la descrive nei dettagli, affidando evidentemente l’aspetto esecutivo alle competenze professionali degli esperti chiamati in causa.

Inizio pagina

Salta inserzione pubblicitaria

La conformità alle WCAG 2.0

La prima cosa da precisare è che, essendo le WCAG 2.0 ancora allo stato di bozza all’epoca della pubblicazione di questo libro, le informazioni che riportiamo di seguito sono da considerarsi assolutamente provvisorie e soggette a modifiche anche radicali.

Ciò premesso, non si può fare a meno di notare un’importante differenza tra le WCAG 2.0 e le WCAG 1.0, per quanto riguarda conformità e validazione.

Nelle WCAG 1.0, la sezione dedicata alle regole di conformità è a dir poco stringata: si limita a precisare che esistono tre livelli di conformità e a elencare quali punti di controllo devono risultare applicati per ciascun livello, affinché si possa dichiarare di aver raggiunto la conformità. Per contro, l’appendice A contiene una dettagliata descrizione della procedura di validazione, cioè dei controlli che devono essere fatti per verificare se esiste oppure no conformità alle linee guida: validazione automatica del codice di marcatura, uso di strumenti semiautomatici, controllo della semantica degli elementi, verifica manuale fatta con diversi browser grafici, testuali e vocali, controllo dei testi da parte di un revisore umano ecc.

La parte discrezionale, affidata a chi applica i punti di controllo e all’esame del valutatore, è preponderante nelle WCAG 1.0 rispetto alla definizione di stringenti vincoli di conformità (più di un punto di controllo, come si ricorderà dai capitoli precedenti, contiene prescrizioni ambigue o, quantomeno, espresse in modo tale da lasciare ampia discrezionalità, sia nell’applicazione sia nella verifica).

Da questo punto di vista, le WCAG 2.0 cambiano registro riducendo drasticamente i margini di discrezionalità, e reputiamo che sia un cambiamento molto positivo, se la pratica riuscirà a essere pari alla teoria.

Uno dei modi per ridurre i margini di discrezionalità è aumentare i vincoli di conformità, cosa che le WCAG 2.0 fanno, introducendo ben nove vincoli da rispettare (secondo la bozza del 17 maggio 2007).

Ma, all’aumento dei vincoli di conformità, fa da contrappeso la mancanza di una sezione dedicata alla validazione. Da un lato il meccanismo dei criteri di successo, dall’altro l’aumento dei vincoli di conformità rendono, infatti, inutile definire una procedura di validazione per le WCAG 2.0. Ogni criterio di successo e ogni requisito di conformità sono verificabili per mezzo di precise tecniche applicative, che valgono anche come criteri di validazione.

Facciamo un esempio concreto per chiarire il concetto. Il requisito di conformità numero 4 richiede che, se una pagina web non può essere resa accessibile nel rispetto dei criteri di successo pertinenti al livello dichiarato, allora deve essere disponibile un meccanismo che, dalla pagina non accessibile, porta a una pagina accessibile, conforme in tutto e per tutto ai criteri di successo del livello dichiarato.

Il requisito di conformità è collegato a quattro tecniche che il gruppo di lavoro per le WCAG reputa sufficienti per il suo superamento:

  1. fornire un collegamento all’inizio del contenuto non conforme, che punta a una versione alternativa che soddisfa i criteri di successo corrispondenti al livello di conformità dichiarato;
  2. garantire che il solo modo di raggiungere la versione non conforme è attraverso un collegamento presente nella versione conforme;
  3. usare variabili d’ambiente per gartantire che il solo modo di accedere ai contenuti non conforme sia attraverso contenuti conformi;
  4. usare una tecnica lato server (il file .htaccess) che permetta di raggiungere il contenuto non conforme solo da un contenuto conforme.

Alle quattro tecniche di superamento seguono poi esempi di fallimento, che mostrano come sia possibile mancare il raggiungimento della conformità al requisito 4.

All’esperto che si occupa della valutazione di un sito in base alle WCAG 2.0, non resta a questo punto che esaminare se e come eventuali contenuti non conformi presenti nel sito sono collegati a versioni alternative accessibili: se riscontra che, per ogni pagina, è stata applicata almeno una delle quattro tecniche sufficienti, allora c’è conformità alle WCAG 2.0 per il requisito 4, altrimenti no. Il livello di discrezionalità della valutazione sembra in questo caso davvero molto basso.

I nove requisiti di conformità

Riportiamo ora in traduzione italiana i nove requisiti di conformità elencati nella sezione Conformance Requirements collegamento esterno della bozza del 17 maggio 2007 delle WCAG 2.0.

  1. Conformità di livello A. Per la conformità di livello A (il minimo livello di conformità), la pagina web soddisfa tutti i criteri di successo di livello A, oppure la pagina è conforme al requisito 4.
  2. Conformità di livello AA. Per la conformità di livello AA, la pagina web soddisfa tutti i criteri di successo di livello A e livello AA, oppure la pagina è conforme al requisito 4.
  3. Conformità di livello AAA. Per la conformità di livello AAA, la pagina web soddisfa tutti i criteri di successo di livello A, livello AA e livello AAA, oppure la pagina è conforme al requisito 4.
  4. Versioni alternative. Se la pagina web non soddisfa tutti i criteri di successo per uno specifico livello, allora può essere derivato dal contenuto non conforme o dal suo URI un meccanismo per ottenere una versione alternativa che soddisfa tutti i criteri di successo, e il meccanismo soddisfa tutti i criteri di successo per lo specifico livello di conformità. Non è necessario che la versione alternativa corrisponda pagina per pagina all’originale (per esempio: l’alternativa a una pagina può consistere di molteplici pagine). Se sono disponibili versioni in più lingue, le versioni conformi sono richieste per ciascuna lingua disponibile.

    [Inizio approfondimento] Un requisito a rischio

    Una nota redazionale aggiunta al requisito 4 avverte i lettori che il gruppo di lavoro è in dubbio se mantenere oppure no questo requisito di conformità alle WCAG 2.0 nella forma in cui è espresso. Teme infatti che “non siano stati identificati abbastanza meccanismi supportati per soddisfare i bisogni e i vincoli di differenti tecnologie o le limitazioni che gli autori possono avere nei loro contenuti o nel server”. È possibile quindi che revisioni future dell’attuale bozza di lavoro presentino una formulazione differente del requisito. [Fine approfondimento]

    [Inizio approfondimento] Il concetto di meccanismo

    La parola “meccanismo” è usata numerose volte nel testo delle WCAG 2.0 (si veda il Capitolo 20), ed è usata anche nell’enunciato del requisito di conformità numero 4. Il glossario accluso alla bozza di Raccomandazione definisce un meccanismo come “un processo o una tecnica per ottenere un risultato”. La definizione è accompagnata da due note. La prima spiega che “il meccanismo può essere esplicitamente fornito nel contenuto oppure si può fare assegnamento sul fatto che sia fornito dalla piattaforma o dal programma utente, comprese le tecnologie assistive”. La seconda nota avverte che “il meccanismo deve soddisfare tutti i criteri di successo per il livello di conformità dichiarato”. [Fine approfondimento]

  5. Solo tecnologie supportate per l’accessibilità. Per soddisfare i criteri di successo si fa affidamento solo su tecnologie web con supporto documentato per l’accessibilità. Qualsiasi informazione o funzionalità che è implementata per mezzo di tecnologie che non sono supportate per l’accessibilità deve essere disponibile anche attraverso tecnologie che sono supportate per l’accessibilità.
  6. Non interferenza. Se in una pagina sono usate tecnologie web che non sono supportate per l’accessibilità, o sono usate tecnologie supportate per l’accessibilità ma in un modo non conforme, allora esse non bloccano la capacità degli utenti di accedere al resto della pagina. In particolare:
    1. Niente trappole per la tastiera. Se usando un’interfaccia a tastiera il focus può essere passato a tecnologie che non sono supportate per l’accessibilità, allora il focus può essere spostato via da quel contenuto usando soltanto un’interfaccia a tastiera, e il metodo per riuscirci è descritto prima che il contenuto sia incontrato e in un modo che soddisfa tutti i criteri di successo di livello A.
    2. Tre lampi o sotto la soglia. Per minimizzare il rischio di attacchi dovuti a fotosensitività, il contenuto non contiene nulla che lampeggi più di tre volte per ogni secondo, o il lampo è al di sotto della soglia generale di lampeggiamento e della soglia del lampo rosso (criterio di successo 2.3.1).
    3. Supporto mancante. Il contenuto continua a soddisfare i requisiti di conformità quando la tecnologia (non supportata per l’accessibilità) è attiva, disattiva o non supportata da un programma utente.
  7. Pagine complete. La conformità riguarda soltanto pagine web complete, e non può essere ottenuta se parte di una pagina web è esclusa.
  8. Informazioni supplementari. Allo scopo di determinare la conformità, un’alternativa conforme a una parte del contenuto di una pagina è considerata parte della pagina.
  9. Processi completi. Se una pagina web che fa parte di un processo non è conforme a un dato livello, allora non viene dichiarata la conformità per quel livello per alcuna pagina web che fa parte del processo. Esempio: un negozio online ha una serie di pagine che sono usate per scegliere e acquistare prodotti. Tutte le pagine nella serie, dall’inizio alla fine (il pagamento), devono essere conformi, affinché si possa dichiarare la conformità per una qualsiasi pagina che fa parte del processo.

Tra i nove requisiti di conformità ci sembrano particolarmente importanti il 5 e il 6. Affinché l’idea che essi esprimono possa funzionare realmente, è però indispensabile che siano rese disponibili delle liste pubbliche di tecnologie web con supporto documentato per l’accessibilità (si veda per maggiori dettagli il paragrafo Nascita e morte del concetto di baseline nel Capitolo 20).

L’importanza dei due requisiti citati sta nell’idea che l’accessibilità possa andare di pari passo con l’innovazione tecnologica. In un sito accessibile conforme alle WCAG 2.0 non sarà proibito utilizzare nuove tecnologie non ancora supportate per l’accessibilità: l’importante è che esista un’alternativa conforme per ogni contenuto veicolato tramite nuove tecnologie non supportate, e che i contenuti non conformi non interferiscano con il normale utilizzo del sito da parte di utenti con disabilità.

Inizio pagina

Le dichiarazioni di conformità alle WCAG 2.0

Le regole per dichiarare la conformità alle WCAG 2.0 sono descritte nella sezione Conformance claims collegamento esterno della bozza di maggio 2007.

In primo luogo, le dichiarazioni di conformità sono ammesse per singole pagine web e per insiemi di pagine web (siti o sezioni di un sito). In secondo luogo, non è obbligatorio pubblicare una dichiarazione di conformità alle WCAG 2.0, ma, se la si pubblica, allora deve contenere le seguenti informazioni:

  1. la data della dichiarazione;
  2. il titolo delle linee guida, la versione e l’URI finale della Raccomandazione;
  3. il livello di conformità soddisfatto (Livello A, AA o AAA);
  4. l’estensione di pagine web, compresi eventuali sottodomini, alle quali si applica la dichiarazione;
  5. la lista di tutte le tecnologie (e relative versioni) dotate di supporto per l’accessibilità, sulle quali le pagine dichiarate conformi fanno assegnamento.

È possibile poi aggiungere, a integrazione della dichiarazione, i seguenti elementi facoltativi:

  1. una lista di ulteriori criteri di successo soddisfatti, che appartengono a livelli di conformità superiori a quello dichiarato;
  2. la lista delle tecnologie utilizzate, sulle quali non è stato fatto assegnamento per la conformità (tecnologie, cioè, che, se non supportate o non attive in un programma utente, non invalidano la conformità delle pagine al livello di accessibilità dichiarato);
  3. l’elenco dei programmi utente, tecnologie assistive comprese, con i quali i contenuti sono stati testati;
  4. informazioni su qualsiasi passo ulteriore che sia stato intrapreso per elevare il livello di accessibilità oltre quello garantito dal rispetto dei criteri di successo;
  5. l’elenco di tecnologie assistive su cui viene fatto assegnamento, codificato in forma di metadati leggibili dalle macchine;
  6. una versione della dichiarazione di conformità codificata in forma di metadati leggibili dalle macchine.

Poiché spesso gli esempi valgono più delle parole, traduciamo di seguito in italiano uno degli esempi di dichiarazione di conformità contenuti nel documento Understanding WCAG 2.0 collegamento esterno.

[Inizio approfondimento] Un esempio di dichiarazione di conformità alle WCAG 2.0

Il 5 maggio 2008, la pagina G7: An Introduction, http://telcor.example.com/nav/G7/intro.html, è conforme alle Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/). Conformità Doppia-A.

[fine approfondimento]

Dichiarazioni di conformità parziale

Un’interessante novità delle WCAG 2.0 sono le dichiarazioni di conformità parziale. Il contesto di riferimento di tali dichiarazioni è il seguente:

Talvolta, vengono create pagine web a cui saranno aggiunti successivamente contenuti addizionali. Per esempio, un programma per le e-mail, un blog, un articolo che consente agli utenti di aggiungere commenti alla fine o applicazioni che supportano contenuti generati con il contributo degli utenti. Un altro esempio potrebbe essere una pagina composta di contenuti aggregati da molteplici contributori, come accade nei portali o nei siti di notizie. In certi casi, i contenuti da altre fonti sono automaticamente inseriti nelle pagine a scadenze prefissate.

Insomma, quando una pagina web è strutturata in modo tale che i responsabili non sono in grado di garantire la conformità materiale di tutte le sue parti alle WCAG 2.0, si presentano due scelte possibili:

Inizio pagina

Tasti di accesso rapido: Indice generale 0 | Capitolo precedente 1 | Capitolo successivo 2 | Glossario 3 | Indice analitico 4 | Torna a inizio pagina 5 | Diodati.org 6 | Forum accessibili 7 | Commenti dei lettori 8 | Recensioni e citazioni 9
Creative Commons License
Accessibilità Guida completa versione HTML by Michele Diodati is licensed under a Creative Commons Attribuzione-Non commerciale-Non opere derivate 2.5 Italia License.