[Salta il menu][L'elefantino con la matita, logo del sito]

Diodati.org | Accessibilità e traduzioni dal W3C      Leggi Omega Centauri!

Considerazioni conclusive

Il testo che segue è un commento di Michele Diodati. Non fa parte dello studio sui requisiti per la verifica dell'accessibilità, riportato nelle pagine precedenti e disponibile in originale sul sito di PubbliAccesso.

Lo studio sui requisiti e le metodologie per la valutazione dell'accessibilità pubblicato su PubbliAccesso è un tentativo sicuramente meritorio di definire delle regole il più possibile semplici e obiettive per la regolamentazione di una materia nuova ed ancora in evoluzione, come è in effetti l'accessibilità.

Le critiche esposte nei miei commenti non vogliono quindi assolutamente essere demolitorie. Il loro scopo è invece quello di cercare di portare alla riflessione degli autori dello studio, ora che è ancora possibile - mi auguro - apportare dei correttivi, ciò che nel loro lavoro mi è apparso impreciso e bisognoso di correzione. Si tratta naturalmente di miei punti di vista, anche se sostanziati da anni di esperienza nel settore e da una serie di riferimenti a quegli stessi documenti normativi internazionali, a cui anche lo studio in esame afferma esplicitamente di richiamarsi.

Ecco dunque di seguito le considerazioni conclusive del sottoscritto, con la speranza che possano servire ad integrare e migliorare i requisiti per l'accessibilità che trapasseranno nel decreto di attuazione della legge.

Sommario

  1. Sulla differenza tra criteri tecnici e criteri soggettivi
  2. La necessità di una formulazione più rigorosa dei requisiti tecnici
  3. Allestire una completa e chiara documentazione di supporto
  4. Formazione
  5. L'accessibilità del linguaggio

1. Sulla differenza tra criteri tecnici e criteri soggettivi

Va chiarita meglio la differenza tra requisiti tecnici e requisiti soggettivi. I due termini non sono realmente opposti. Proporrei di sostituire la parola "tecnici" con "oggettivi", intendendo con ciò i requisiti che possono essere esaminati o in modo automatico (validazione del codice, esame tramite programmi come Bobby o Torquemada) o tramite una verifica umana basata su precisi criteri di riferimento (raggruppare le sequenze di link, verificare che la pagina possa essere ingrandita fino al 200%, ecc.). A questo punto acquisterebbe chiarezza l'opposizione con i requisiti soggettivi, intendendo con questi ultimi quelli che non possono essere verificati se non tramite esperimenti con utenti umani (la comprensibilità dei testi, la coerenza del sistema di navigazione, la facilità di apprendere il funzionamento dell'interfaccia, ecc.).

Tuttavia i requisiti che fanno parte della prima categoria e quelli che fanno parte della seconda non sono sempre ben distinti e ben distinguibili. Nella prima categoria, per esempio, si trova la valutazione delle alternative equivalenti per contenuti grafici, multimediali o di programmazione. Accertarsi della presenza di un'alternativa è certamente un criterio oggettivo; valutare quanto quest'alternativa sia adeguata è invece tutt'altra storia: è un requisito che dovrebbe essere spostato a mio parere tra le valutazioni soggettive, da svolgersi per mezzo di test con utenti.

D'altro canto, nella seconda categoria abbiamo all'undicesimo posto il criterio della flessibilità, che, almeno nella misura in cui coinvolge il ridimensionamento della pagina e dei caratteri, è qualcosa che può essere valutato in base a criteri oggettivi.

Insomma, la distinzione tra le due categorie non è sempre chiara ed agevole. Ciò che fa la differenza sono soprattutto i criteri metodologici da utilizzare per la verifica: strumenti automatici e prove tecniche nel primo caso; esperimenti su utenti nel secondo. Ciò giustifica anche il ricorso a due figure professionali differenti: il tecnico "accessibilista" nel primo caso, l'ergonomo (ma meglio sarebbe lo psicologo cognitivista e l'usabilista) nel secondo.

torna su

2. La necessità di una formulazione più rigorosa dei requisiti tecnici

La parte dello studio che mi sembra in assoluto più bisognosa di modifiche è quella relativa ai venti requisiti tecnici. Come attestano i numerosi commenti che ho intervallato al testo degli enunciati, in molti casi la formulazione è imprecisa. Oscillando tra i riferimenti alle WCAG 1.0 e quelli a Section 508, i requisiti formulati non hanno una personalità precisa; sono ricavati non di rado "cucendo" tra loro con suture non perfette pezzi non omogenei delle WCAG 1.0 o di Section 508. L'effetto di questo collage non è dei migliori.

In particolare trovo dannosa la scelta che si è fatta di sconsigliare piuttosto che di proibire; o di vietare, per rendere poi ammissibile al rigo successivo ciò che era stato appena proibito. Rende ancora più indeterminato il tutto il fatto che i divieti o le concessioni si legano quasi inevitabilmente a condizioni enunciate in termini vaghi (le "esigenze informative" del requisito 5, l'alta leggibilità del requisito 6, il "nonostante ogni sforzo" del requisito 20, ecc.).

In verità lo stile espressivo degli enunciati non è una novità: ricalca l'indeterminatezza (spesso però peggiorandola senza necessità) di molte raccomandazioni delle WCAG 1.0. Tuttavia, mentre lì l'indeterminatezza era in un certo senso accettabile, perché le WCAG sono raccomandazioni, semplici consigli, e non obblighi di legge, nel caso dei requisiti per il decreto di attuazione della legge 4/2004 la situazione è rovesciata, e quello che nelle WCAG era un pregio diventa qui un grave difetto.

La mia opinione è che, se si vuole che la legge sull'accessibilità sia realmente e largamente applicabile, occorre definire nel modo più chiaro, preciso ed inequivocabile ciò che può essere fatto e ciò che non può essere fatto. Questo non vuol dire creare vincoli di difficile applicazione. Non sto dicendo che bisogna stabilire regole dure, ma che bisogna stabilire regole più precise. Possiamo cioè anche allentare la rigidezza dei requisiti richiesti, ma è di fondamentale importanza che non si mettano lo sviluppatore e il valutatore nella condizione di non essere certi di cosa occorra fare per soddisfare un dato requisito tecnico: questa scritta sarà ad alta leggibilità oppure no? è stato fatto davvero ogni sforzo per evitare la pagina alternativa oppure no? quel testo lampeggiante risponde ad un'esigenza informativa indispensabile oppure no? E così via...

Ma ben più grave del problema psicologico dei dubbi che potrebbero attanagliare lo sviluppatore ed il valutatore è la questione della mancanza di oggettività delle valutazioni di accessibilità che verranno prodotte sulla scorta di requisiti imprecisi. Più è indeterminato il criterio da seguire, più alta è la possibilità che valutatori diversi interpretino in modi completamente differenti le richieste di un medesimo requisito: la conseguenza potrebbe essere che un sito meritevole venga considerato meno accessibile di un altro non meritevole... Senza considerare i rischi di comportamento disonesto a cui la vaghezza dei requisiti spianerebbe la strada.

torna su

3. Allestire una completa e chiara documentazione di supporto

Un altro grosso problema emerso dalla lettura di questo studio è che poggia praticamente... sul nulla. Non c'è un glossario allegato, non sono spiegati i significati dei termini tecnici adoperati, non è descritto come ottenere i risultati che i requisiti stabiliti richiedono di ottenere.

Immagino che sia stata già prevista dagli estensori dello studio la necessità di fornire ai soggetti interessati dall'applicazione di questa legge una documentazione di supporto, che serva come riferimento e come orientamento nel lavoro di messa a punto dell'accessibilità.

Tale documentazione è indispensabile: l'applicazione stessa della legge riuscirà difficile e nebulosa, se non verranno messi a disposizione opportuni testi di riferimento, glossari, documenti di specifiche, esempi di applicazione delle regole di accessibilità.

Non mi sembra sufficiente né corretto limitarsi ad indicare, come è stato fatto, le fonti in inglese - raccomandazioni W3C, paragrafo 1194.22 della Sezione 508, norme ISO - a cui lo studio è ispirato. Lo sviluppatore ed il valutatore italiani non sono tenuti a conoscere l'inglese (o a conoscerlo così bene da usarlo come lingua di lavoro): hanno bisogno di riferimenti normativi in lingua italiana. Non solo: dal momento che i requisiti definiti in questo studio costituiscono una nuova formulazione in materia di accessibilità, evidentemente non possono rimandare tout court ai documenti in inglese che spiegano e regolano l'accessibilità così come è definita nelle WCAG 1.0, in Section 508, negli standard ISO. Se questo studio definisce uno standard italiano per l'accessibilità, deve anche fornire agli interessati strumenti tecnici originali, comprensibili e pertinenti, per consentire di adeguarvisi.

Gli strumenti tecnici a cui mi riferisco sono i seguenti:

Come ulteriore materiale di supporto e consultazione, sarebbe opportuno preparare anche traduzioni ufficiali delle raccomandazioni WCAG 1.0 (una traduzione in italiano delle WCAG 1.0 è stata realizzata anni fa dai volontari dell'AIB) e delle tecniche di applicazione associate, nonché traduzioni del documento in inglese che illustra gli enunciati e le modalità di applicazione dei requisiti di Section 508. Ciò perché tale documentazione viene ripetutamente richiamata come fonte ispiratrice dei requisiti definiti nello studio qui in esame.

torna su

4. Formazione

Le complesse modalità di valutazione dell'accessibilità descritte nei paragrafi 1.2 e 1.4 di questo studio portano in primo piano l'esigenza di formare delle professionalità adeguate ai compiti previsti. Come ha osservato Maurizio Boscarol in un suo recente articolo già citato in precedenza, l'ergonomia è una disciplina troppo generica per presumere che, fin da subito, chi oggi è qualificato come ergonomo sia anche in grado di compiere valutazioni professionali dell'accessibilità di siti e applicazioni web.

Occorre a mio parere che ci si preoccupi di formare delle professionalità apposite, cioè degli esperti che conoscano a fondo l'accessibilità e l'usabilita dei siti web, discipline che da sole richiedono molteplici e raffinate competenze. Dal punto di vista del solo controllo tecnico dell'accessibilità occorre:

Dal punto di vista del controllo dell'usabilità occorre poi che l'esperto sia in grado di organizzare test con utenti disabili e non, traendone valutazioni corrette e sufficientemente oggettive circa il grado di applicazione dei vari requisiti elencati al paragrafo 1.3 dello studio.

Benché sia comprensibile la scelta, da parte degli esperti designati dal legislatore, di affidare all'ergonomo tali valutazioni, una simile scelta è a mio parere troppo limitativa e riduttiva, rispetto alle competenze che fin da oggi occorre mettere in campo. Non è troppo tardi per modificare questo punto dello studio, riformulando la questione in modo da definire magari professionalità e percorsi formativi appositi, che permettano nel corso di un tempo accettabile di formare degli esperti valutatori, dotati di adeguate competenze settoriali.

torna su

5. L'accessibilità del linguaggio

Un punto generalmente trascurato da chi si occupa di accessibilità come tecnico è la verifica che il linguaggio adoperato nelle pagine web sia realmente adeguato al pubblico a cui ci si rivolge. Si è creata una sorta di fraintendimento implicito, che porta chi si occupa di accessibilità a profondere lavoro e attenzione nell'adeguamento della grafica e del codice di marcatura ai requisiti di accessibilità previsti dalle specifiche WCAG 1.0, trascurando quasi del tutto il lavoro sui contenuti e sullo stile comunicativo.

Ciò è un grave errore ed un grave handicap in vista del raggiungimento di una vera accessibilità. Questa è, infatti, per il 50% lavoro sul codice e sulla cornice tecnologica, ma per un altro 50% lavoro sui contenuti testuali e sulla lingua. Non è possibile considerare accessibile un documento che rispetta tutti i requisiti previsti tranne uno: è scritto - come spesso accade - in ostrogoto.

Mettendosi purtroppo nel solco del fraintendimento appena descritto, lo studio qui in esame non dà quasi nessun rilievo al problema dell'accessibilità del linguaggio con cui sono espressi i contenuti. Solo tra gli esempi relativi al requisito soggettivo 2 ("uso") si fa un generico ed insoddisfacente accenno al problema dell'accessibilità del linguaggio: Utilizzare un linguaggio comprensibile alla grande maggioranza dei destinatari.

In tal modo l'importanza di testi accessibili risulta enormemente sottovalutata. Bisognerebbe invece riflettere sul fatto che il testo è l'elemento di interscambio vero e proprio dell'accessibilità: senza testi adeguati, la migliore cornice tecnologica ad alta accessibilità è una scatola vuota, un sepolcro inutile. Come minimo, alla valutazione del linguaggio dovrebbe essere dedicato un requisito soggettivo a sé, identificato come fattore della massima importanza (livello *) per il conseguimento dell'accessibilità.

A supporto degli autori e dei valutatori dovrebbero poi essere forniti adeguati strumenti di consultazione e di riferimento: repertori lessicali tecnici per scegliere i termini più adatti al discorso, manuali di stile, corsi di formazione linguistica, guide alla semplificazione dei linguaggi settoriali (si pensi ai disastri del burocratese), esperti in grado di fornire consulenze linguistiche.

Ripeto: l'intervento sull'accessibilità cognitiva di ciò che attraverso il Web viene comunicato è almeno altrettanto importante dell'intervento sull'accessibilità percettiva: i contenuti devono essere facilmente e chiaramente comprensibili, oltre che ben percepibili.

Curare nei dettagli tutta la cornice tecnologica di supporto (codice valido, elementi alternativi, contrasti di colore, menu di navigazione coerenti, caratteri ridimensionabili, ecc. ecc.) e trascurare l'accessibilità dei testi immessi in quella cornice è un po' come invitare ad una tavola da re - imbandita con tovaglie finissime, piatti di porcellana, bicchieri di cristallo, posate d'argento e portate raffinatissime - una tribù di uomini di Neanderthal: potrebbe essere divertente, questo sì, ma quanto all'utilità...

torna su

*Vai a: Diodati.org > Guide, articoli, scritti > Studio (commentato) sulle linee guida
*Scrivi: info@diodati.org
*Ultima modifica: 20/10/2012 ore 01:02