WebQuality   Note sulla qualità del Web

Indice sinottico

1. Scopo di questo documento
2. Debolezze tecniche relative ai requisiti tecnici
3. Debolezze metodologiche
4. Alcuni rimedi

Scopo di questo documento

Lo scopo di queste note è di mettere in evidenza alcuni aspetti tecnici relativi alla legge 4 del 9/1/2004 ("legge Stanca") e allegati (www.pubbliaccesso.gov.it/normative/DM080705.htm) che sono subottimali e che potrebbero essere migliorati. Il problema è che la presenza di questi difetti rende più difficile e arbitraria l'osservanza della legge, riducendone i benefici.

I commenti che seguono vertono soprattutto sugli aspetti tecnici, e non su quelli legali, per i quali suggerirei di consultare www.webimpossibile.net/05/3.11.05.htm

Per un confronto tecnico tra i requisiti della legge Stanca e quelli della sezione 508 statunitense e i criteri di successo previsti da una recente bozza delle WCAG 2.0 si veda la mia nota sulle corrispondenze.

Debolezze tecniche relative ai requisiti tecnici

I seguenti commenti, mie personali opinioni, sono basati sulla mia esperienza di quali siano le barriere importanti che limitano l'uso del web da parte di persone disabili di vista, di udito, motori o cognitivi. In particolare non derivano da dati sperimentali.

1. nessun requisito richiede che documenti PDF (una grammatica formale pubblicata, anche se di proprietà) siano resi accessibili (trasformandoli in documenti equivalenti in HTML o marcandoli opportunamente, come il formato PDF prevede); dei PDF si richiede solo la validità sintattica.
   Rettifica del 20/3/2008 In effetti, trattandosi di una grammatica formale pubblicata, tutti i requisiti previsti dal regolamento si applicano in linea di principio. Non si tratta quindi di un limite della legge. Mi scuso per l'errore.
2. nessun requisito richiede che il contenuto delle pagine sia suddiviso in sezioni, usando i tag H1-H6; eppure l'assenza di questi accorgimenti rende molto dispendiosa e confusa la fruizione di una pagina mediante un lettore di schermo
3. nessun requisito richiede che le pagine siano dotate di tasti rapidi (accesskey) associati a delle funzionalità frequentemente usate, che migliorerebbero le prestazioni di utenti che non possono o non vogliono usare il mouse (ad es. in una applicazione all'interno di una intranet)
4. nessun requisito richiede che link adiacenti siano separati da caratteri pronunciabili (qualora non si usino delle liste UL, ad esempio); spesso però i lettori di schermo pronunciano i link uno dopo l'altro senza nessuna separazione udibile tra loro
5. nessun requisito richiede che le pagine abbiano dei titoli informativi, non ambigui e differenti tra loro, altro fattore la cui assenza rende confusa la fruizione delle pagine tramite lettori di schermo
6. nessun requisito richiede in maniera esplicita che si verifichi il modo con cui il cambiamento del focus dell'input avviene; talvolta il cambiamento del focus non avviene per effetto di un input dell'utente (ad es. l'attivazione di un refresh temporizzato della pagina) e talvolta anche se avviene per effetto di un'azione dell'utente, il cambiamento del focus è imprevedibile (ad es. la selezione da una combo box che causa un HTTP post, e quindi un refresh della pagina); in questi casi l'uso di tecnologia assistiva o anche della sola tastiera rende non fruibile il sito
7. nessun requisito richiede in maniera esplicita una gestione accessibile degli errori di compilazione di una form, ed è risaputo che la comprensione e l'utilizzo delle form è una delle cose più difficoltose
8. nessun requisito richiede che i campi e i controlli delle form siano adeguatamente raggruppati e titolati (usando FIELDSET e LEGEND)
9. nessun requisito richiede la marcatura per identificare la lingua con cui le parole vanno pronunciate
10. un requisito vieta l'uso delle pagine solo testo, mentre delle pagine solo testo fatte bene (cioè accessibili) risultano efficaci in molte situazioni (si veda a tal proposito alcuni articoli da me pubblicati)
11. le formule e i criteri per calcolare i sufficienti livelli di contrasto luminoso e cromatico tra colore di sfondo e colore di primo piano sono criticabili, in quanto siti che violano tali criteri risultano a tutti gli effetti ben accessibili; si veda www.contrastocolori.org per delle discussioni dettagliate e controesempi
12. un requisito richiede che le pagine siano scritte in (X)HTML con DTD strict: si tratta di una caratteristica che rende le pagine sicuramente di elevata qualità (almeno dal punto di vista dei linguaggi di rappresentazione usati), ma sebbene l'ottenimento di questa proprietà spesso sia molto costoso in termini di tempo, sforzo, conoscenze (ad es. quando si usano delle applicazioni pre-esistenti con interfaccia web, come un CMS), l'impatto che tale proprietà ha rispetto all'accessibilità è minimo (nella mia esperienza non mi è mai capitato di osservare un disabile "inciampare" su un sito perché le pagine non fossero valide sintatticamente). È vero: pagine non valide rischiano di non far funzionare correttamente un browser (mi sta succedendo questo ogni mattina: l'applicazione web che devo usare nell'albergo in cui sono per attivare la connessione in rete prevede il click di un pulsante immagine che è codificato in maniera non valida così <img src="..." onclick="..." >; Internet Explorer interpreta l'immagine con un oggetto cliccabile e mi permette di andare avanti; Firefox no). Però sempre questi malfunzionamenti influenzano tutti gli utenti, non solo coloro che sono disabili o che usano una tecnologia assistiva. E quindi il ripulire le pagine da questo tipo di difetto è un intervento che, a mio avviso, esula dall'accessibilità.

Debolezze metodologiche

Da un punto di vista metodologico si vorrebbe poter impiegare dei metodi che siano di qualità:

• validi, e cioè che permettano di catturare la proprietà a cui siamo interessati (l'accessibilità)
• affidabili, e cioè che siano ripetibili nel senso che valutatori simili in situazioni simili producano risultati simili per gli stessi siti
• economici, in termini di sforzo, tempo, competenze, persone.

Temo che per quanto riguarda l'accessibilità in generale, nel mondo, non si sia ancora giunti a tale stato di cose. Per quanto riguarda la legge Stanca si possono rilevare i seguenti difetti:

1. Alcuni requisiti non sono testabili: ad es. il requisito 5, se si causa o favorisce un attacco epilettico, non fornisce alcun dettaglio su come decidere.
2. I legami con i checkpoint delle WCAG 1.0 e i paragrafi della section 508 ci sono ma non sono normativi, sono solo di riferimento; quindi dovrebbero servire solo per generica informazione, e non per determinare se un sito viola o meno quel requisito; tutto ciò rende ambigui gran parte degli enunciati dei requisiti, con la conseguenza che la loro verifica diventa più soggettiva di quello che sarebbe potuta essere.
3. La verifica tecnica si conclude con un esito binario, senza necessariamente fornire delle indicazioni su diverse priorità che le violazioni dei requisiti possono avere; tali priorità sono invece essenziali per chi deve decidere quali difetti risolvere in condizioni di risorse scarse.
4. La verifica tecnica richiede che le pagine vengano esaminate con vari browser e si verifichi la fruibilità dei contenuti delle pagine sotto varie condizioni. In alcuni casi è relativamente semplice farlo (ad es. verificare la fruibilità dei contenuti una volta che le immagini vengano disabilitate), in altri invece richiede di esprimere dei giudizi molto soggettivi (es. verificare che i contenuti della pagina siano fruibili in caso di utilizzo delle funzioni previste dai browser per definire la grandezza dei caratteri).
5. I metodi suggeriti per la verifica soggettiva includono la simulazione cognitiva. Se per "simulazione cognitiva" si intende "cognitive walkthrough" (si veda usability evaluation methods) allora la sua efficacia per la verifica dell'accessibilità è ancora da dimostrarsi. Si tratta infatti di un metodo usato durante le fasi di sviluppo di un sistema interattivo secondo il quale uno dei progettisti fa le veci dell'utente e "percorre" le varie videate del programma spiegando ai suoi colleghi quali siano le necessarie ipotesi sul modello mentale dell'utente affinché l'interazione abbia successo. è possibile che tale metodo funzioni per la verifica dell'accessibilità, ma non esistono ricerche in tale senso che ne dimostrino l'efficacia. Dato che la normativa prevede che si considerino 12 principi generali di usabilità, è possibile che l'arcano sia dovuto semplicemente ad un errore di stampa: il metodo da applicare è quello della simulazione euristica ("heuristic walkthrough"; in una mia nota ne propongo una variante adattata all'accessibilità.
6. La normativa prevede anche che il valutatore (che svolge la verifica soggettiva) assegni dei giudizi di qualità, articolati su 5 livelli, per caratterizzare quanto bene il sito implementa ciascuno dei 12 principi. Purtroppo non si da alcuna indicazione su come assegnare i livelli di qualità, lasciando aperta la possibilità di un'ampio grado di discrezionalità.
7. La verifica soggettiva prevede la costituzione di un gruppo di utenti a cui chiedere di usare il sito in completa autonomia e fornire delle opinioni (metodo chiamato "subjective assessment") alternativamente tali utenti possono essere coinvolti in sessioni di test (metodo chiamato "user testing) in cui uno alla volta cerca, sotto osservazione, di svolgere dei compiti assegnati dal valutatore, e quest'ultimo individua le situazioni in cui l'utente "inciampa" e, alla fine, stila una diagnosi del sito.
   Anche in questo caso la normativa vincola molto poco il valutatore, sia nella scelta del metodo, che nel modo di applicarlo, col risultato di lasciare un alto grado di discrezionalità. Anche in questo caso il valutatore deve produrre dei giudizi qualitativi articolati in 5 livelli.
8. La sintesi del livello di qualità finale, secondo quanto previsto, deve procedere con il calcolo dei valori medi dei vari livelli qualitativi, e fornire un giudizio articolato in 4 possibili livelli. In questo caso non è ovvio che questo modo di procedere nella sintesi dei livelli di qualità sia efficace e fornisca un indice finale che veramente sia indicativo del livello di qualità riscontrato.
9. La verifica soggettiva mira a verificare l'usabilità (o meglio qualità d'uso) del sito da parte del disabile, che è un concetto diverso da quello di accessibilità (per accessibilità spesso si intende la proprietà del sito di permettere al disabile di ottenere le stesse informazioni o servizi del non disabile). Per ottenere e per verificare il livello di usabilità rispetto ai disabili, i metodi di analisi, progetto, realizzazione e test dei siti richiedono livelli di competenza sicuramente maggiori di quelli oggigiorno messi in pratica nella realizzazione di siti e applicazioni web. Sebbene sia una buona intenzione, a mio avviso resterà inapplicabile (se fatta seriamente).
10. Infatti due dei metodi suggeriti per la verifica soggettiva (test con utenti e subjective assessment) sono relativamente complessi da organizzare nel caso di utenti disabili (è difficile trovare campioni rappresentativi delle varie disabilità e che abbiano i necessari requisiti di screening; difetti di bassa usabilità in generale del sito costituiscono fattori di disturbo, è difficile la logistica: bisogna trovare stanze e apparecchiature che siano familiari agli utenti).
11. La legge prevede la certificazione dell'accessibilità; recentemente l'EICTA (l'associazione europea delle industrie dell'ICT) ha stilato un rapporto in cui elenca le ragioni per cui è contraria ad un processo di certificazione da parte di terze parti dell'accessibilità:
    1. tendenza a congelare l'innovazione dato che direziona attenzione e risorse sul superamento della certificazione (sindrome del "minimo comune denominatore") invece che sul miglioramento del prodotto
    2. rallenta l'introduzione sul mercato dei prodotti
    3. porta a duplicazione di sforzi e costi, dato che un processo di verifica interno è comunque necessario
    4. tende a confondere aumento della qualità con verifica della conformità
    5. aumenta il prezzo finale dei prodotti
    6. scoraggia ricerca e sviluppo in direzioni equivalenti
    7. è poco praticabile vista la soggettività intrinseca nelle proprietà valutate (accessibilità) e il livello di competenze necessarie per svolgerla in maniera valida e ripetibile
    8. non produce gli effetti desiderati visto lo spettro di diverse abilità degli utenti considerati
    9. genera false aspettative nella clientela e quindi sarebbe occasione di dispute legali.
    Per queste ragioni l'EICTA è a favore di un'auto certificazione, da parte di chi produce il sito, che sia basata (in Europa) su un unico insieme di linee guida, le WCAG.

Alcuni rimedi

A mio avviso bisogna approcciare l'accessibilità da un punto di vista ingegneristico e pragmatico, cercando di bilanciarne i benefici con i costi relativi. Solo in questo modo essa può diventare un fattore di qualità che è sostenibile.

Una prima possibilità di rimedio è di adottare un metodo di valutazione dell'accessibilità che guidi il valutatore fornisca maggiori informazioni al valutatore, in modo da ridurre la soggettività del giudizio. Un metodo di questo tipo è ad esempio la simulazione euristica attualmente in corso di validazione sperimentale. Questo metodo, se guidato dalle barriere, fornisce inoltre dei contesti di riferimento da una parte concreti (e quindi facilmente comprensibili) e dall'altra abbastanza ampi da coprire le esigenze di un gran spettro di disabilità. Se le barriere considerate sono un sovrainsieme di quelle menzionate nei requisiti della legge Stanca si ottiene la conformità come effetto collaterale.

Una seconda possibilità è di definire esplicitamente una politica di accessibilità e delle linee guida aziendali per l'accessibilità che possono essere un raffinamento ed una specializzazione dei requisiti della legge Stanca, o altre. In questo modo sia il concetto di accessibilità, sia gli obiettivi dell'accessibilità, e quindi anche i modi per verificare se la si è ottenuta sono messi in chiaro. Inoltre la specializzazione delle linee guida permette di adattarle sia ai propri scopi che alle caratteristiche e convenzioni adottate nel proprio sito (ad es. per decidere in dettaglio che tipo di testo alternativo dare alle immagini usate nelle intestazioni delle pagine).

La terza strada da seguire per migliorare l'effetto che la legge Stanca ha sulla qualità dei siti web consiste nel rendere il più trasparente possibile il processo di valutazione, pubblicando il rapporto tecnico con una descrizione delle decisioni prese e delle loro motivazioni (magari tale rapporto può essere raggiungibile da un link adiacente al bollino di conformità, insieme alla politica di accessibilità adottata). In questo modo da una parte ci si salvaguarda da interpretazioni discordi di qualche requisito, e dall'altra si dimostra di non aver nulla da nascondere. Inoltre si contribuisce alla società descrivendo le buone pratiche che si sono adottate.