Logo L'ink - Scrittura Professionale l'ink scrittura professionale

"Fare cose con le parole"

Intervista a Michele Diodati

A cura di Giovanni Acerboni, in occasione dell'uscita del volume di Michele Diodati, Accessibilità. Guida completa (Apogeo, 2007), 24 ottobre 2007

1. E' possibile definire sinteticamente cosa si intende per accessibilità?

 

L'accessibilità di cui tratta il libro Accessibilità. Guida completa riguarda unicamente le informazioni e i servizi diffusi in forma digitale e in particolare attraverso il Web. È escluso ogni riferimento all'accessibilità del mondo fisico, quindi non si parla di scivoli, parcheggi riservati, servizi igienici speciali ecc. In questa accezione ristretta, esistono ancora due significati di 'accessibilità' tra i quali occorre distinguere:

  1. l'accessibilità intesa come proprietà di una pagina web, di uno strumento autoriale o di un programma utente (un browser per es.), di essere utilizzabili anche da individui con disabilità o che usano attrezzature obsolete o di nicchia;

  2. l'accessibilità intesa come insieme di raccomandazioni e tecniche, per raggiungere il risultato indicato al punto 1.

2. Che differenza c'è tra queste due accezioni?

La prima accezione riguarda le proprietà di oggetti accessibili, la seconda riguarda invece la materia nel suo insieme. La differenza diventa più chiara per mezzo di un esempio. Se dico "l'accessibilità di questa pagina web è sufficiente (o insufficiente)", sto parlando della proprietà dell'oggetto 'pagina web' di essere utilizzabile senza perdite d'informazione anche da utenti con disabilità o che usano attrezzature datate o poco comuni. Se, invece, dico "l'accessibilità consiglia di non usare le tabelle HTML a scopo di presentazione grafica", mi sto riferendo non più a un singolo oggetto (la pagina web o il browser), ma alla materia che studia come rendere accessibile il Web a utenti con disabilità.

3. Dal punto di vista del navigatore, è più interessante parlare della prima. Quali sono le caratteristiche principali che una pagina deve avere per essere accessibile?

Dal punto di vista del navigatore, la risposta è molto semplice. Una pagina è accessibile, se può leggerne, comprenderne e usarne i contenuti con facilità. Ciò presuppone però un complesso e diversificato lavoro da parte di autori e sviluppatori, che devono implementare in uno stesso documento molteplici caratteristiche differenti, allo scopo di accomodare le necessità dei più disparati tipi di utenza (ciechi, ipovedenti, disabili motori, dislessici, stranieri, possessori di attrezzature obsolete o di nicchia ecc.).

4. Parliamo allora delle caratteristiche di accessibilità dal punto di vista di autori e sviluppatori.

Autori e sviluppatori devono tener presente innanzitutto che una pagina web è accessibile (o inaccessibile) non in senso assoluto, ma nella misura in cui sono stati soddisfatti una serie di requisiti specifici, che possiamo ricondurre sotto tre categorie principali:

  1. aspetto grafico. Una grafica accessibile si caratterizza per la capacità del contenuto di adattarsi alla dimensione della finestra del browser (cosiddetta impaginazione liquida), per la ridimensionabilità dei
    caratteri e per la presenza di un alto contrasto di luminosità tra primo piano e sfondo, valutabile per mezzo di appositi algoritmi;

  2. codice di marcatura e di programmazione. Il codice è il motore nascosto di una pagina web accessibile. In primo luogo, deve garantire un'accurata separazione degli elementi strutturali (titoli, tabelle, paragrafi ecc.) dagli elementi stilistici. Questo obiettivo viene perseguito usando esclusivamente i fogli di stile per attribuire caratteristiche di stile ai documenti (tipo di carattere, grandezza, colori, dimensioni ecc.). In secondo luogo, il codice deve essere scritto in modo da consentire l'utilizzo dei contenuti con qualsiasi dispositivo di input e di output: in termini più semplici, ciò vuol dire che una pagina è accessibile se può essere consultata con successo usando una tastiera e uno screen reader al posto della coppia tradizionale" mouse/monitor. In terzo luogo, il codice deve essere scritto nel rispetto degli standard internazionali esistenti, allo scopo di rendere massima l'interoperabilità, cioè la possibilità che computer e applicazioni differenti possano scambiare dati tra loro senza perdita d'informazioni e di funzionalità;

  3. composizione dei contenuti. Una pagina web è accessibile non solo quando può essere percepita da utenti con limitazioni sensoriali, ma anche (e forse soprattutto) quando può essere capita da chiunque e, in particolare, da chi è affetto da problemi cognitivi permanenti o contingenti. È dunque fondamentale anche il modo in cui sono scritti e assemblati i contenuti. Testi chiari e semplici sono più accessibili di testi contorti e nebulosi. I contenuti multimediali come filmati e animazioni sono più accessibili se sono accompagnati da descrizioni e sottotitolazioni. Un testo tecnico complesso è più accessibile se è collegato ad un glossario e se è corredato da immagini esplicative.

Riassumendo, l'accessibilità dei contenuti diffusi via Web dipende in larga parte dalla capacità di autori e sviluppatori:

  1. di creare strutture flessibili e adattabili;

  2. di fornire alternative equivalenti per i contenuti che si rivolgono a uno specifico canale sensoriale (la vista o l'udito);

  3. di tarare la comprensibilità delle informazioni veicolate sulle capacità degli utenti meno dotati, all'interno del pubblico di riferimento considerato.

5. Infatti il tuo libro si rivolge in primo luogo agli autori e agli sviluppatori. Non mi pare di aver notato nel libro alcunché di superfluo, ma la sua mole è indubbia. Il che significa che rendere accessibile un sito non è un'impresa semplice, perché occorre tener conto di aspetti molto diversi che devono essere realizzati con coerenza. Puoi formulare sinteticamente quale sia l'approccio corretto per chi voglia realizzare un sito accessibile?

In base all'esperienza che ho maturato nel corso degli anni, l'approccio corretto non è quello di applicare l'accessibilità a posteriori, come una specie di optional che si aggiunge a cose fatte. Un sito accessibile deve essere progettato come tale fin dall'inizio. Il capitolo 6 del libro offre un esempio pratico di de-costruzione di una pagina web assemblata secondo criteri non accessibili. La pagina viene ridotta per così dire ai minimi termini, separandone i componenti per mostrarli al lettore: i contenuti nudi e crudi (testi e immagini), la struttura di titoli, paragrafi ed elenchi, infine gli stili grafici. Viene poi ricostruita da zero in modo accessibile, il che vuol dire, in breve: applicare la struttura (titoli, elenchi ecc.) ai puri contenuti, delegando la presentazione - cioè la definizione dell'aspetto grafico - ai fogli di stile. Ciò consente di ottenere un documento flessibile, adattabile a quasi ogni tipo di dispositivo e di fruizione.

La costruzione di un sito accessibile deve essere considerata come una sorta di piramide, in cui i livelli superiori - stili, comportamenti, oggetti incorporati - usano o sostituiscono ciò che sta nei livelli inferiori, senza però obbligare gli utenti ad accedere ai contenuti per mezzo dei livelli superiori. Tutto ciò ha anche un nome, che è 'potenziamento progressivo', in inglese progressive enhancement (ne parlano l'undicesimo e il dodicesimo capitolo del libro).

È degno di nota che costruire un sito col metodo del potenziamento progressivo non è solo un rimedio per l'accessibilità, ma un modo professionale e oserei dire 'ecologico' di approcciare in generale lo sviluppo di siti web: è utile infatti per l'utente, che riesce ad accedere ai contenuti anche con dispositivi obsoleti o alternativi, ma è utile anche per lo sviluppatore, perché l'ordine e la coerenza della 'costruzione' rendono molto più semplice la manutenzione e la modifica di un sito.


6. In Italia abbiamo una legge che impone ai siti delle pubbliche amministrazioni di essere accessibili (legge 4/2004, cosiddetta legge Stanca). E' una legge efficace?

A giudicare da quello che si è visto negli oltre tre anni e mezzo da quando la legge 4/2004 è entrata in vigore, la risposta non può che essere negativa. Sotto l'ombrello di una tensione ideale ammirevole, la legge nasconde una serie di deficienze che ne minano alla radice l'applicabilità. Sintetizzando, i principali problemi applicativi, limitatamente all'accessibilità del Web, sono a mio avviso i seguenti:

  1. la mancanza di un obbligo all'accessibilità almeno per i privati che offrono servizi d'interesse pubblico (penso ai quotidiani online, ai servizi di webmail, ai sistemi di home banking, ai siti di social networking ecc.);

  2. la mancanza di un obbligo generico di accessibilità per gli enti pubblici, dal momento che la legge non impone il rispetto dei requisiti di base se non in presenza di un contratto per la fornitura di siti web;

  3. la forma in cui è stato steso il testo del decreto che contiene i ventidue requisiti tecnici che dettano le regole di accessibilità da implementare: un testo fatto di enunciati formulati con un linguaggio spesso burocratico ed ambiguo, per giunta del tutto privo del supporto di esempi applicativi.


7. Puoi fare qualche esempio?

Un esempio per tutti può essere considerato il requisito 12. È ispirato al punto di controllo 3.4 delle WCAG 1.0, che dice testualmente, tradotto in italiano: "Usate unità relative piuttosto che assolute nei valori di attributo dei linguaggi di marcatura e nei valori di proprietà dei fogli di stile". Lo scopo di questo punto di controllo è garantire un'impaginazione liquida, con testi e contenitori liberamente ridimensionabili dall'utente. Questa raccomandazione, semplice e comprensibile per uno sviluppatore, si è trasformata, nel requisito 12 della legge italiana, nel seguente, complesso enunciato:

"La presentazione e i contenuti testuali di una pagina devono potersi adattare alle dimensioni della finestra del browser utilizzata dall’utente senza sovrapposizione degli oggetti presenti o perdita di informazioni tali da rendere incomprensibile il contenuto, anche in caso di ridimensionamento, ingrandimento o riduzione dell’area di visualizzazione o dei caratteri rispetto ai valori predefiniti di tali parametri".

Qui non si parla più di unità di misura, ma di quali caratteristiche grafiche deve avere una pagina web durante l'interazione con l'utente. Il dettagliatissimo enunciato sembrerebbe fatto apposta per fugare qualsiasi dubbio applicativo, ma in realtà non è così. Fin dall'apparire del decreto, si sono formati due partiti che interpretano diversamente la richiesta del requisito. Per un partito, esso richiede un'impaginazione liquida. La frase "La presentazione e i contenuti testuali di una pagina devono potersi adattare alle dimensioni della finestra del browser utilizzata dall’utente" viene interpretata come una richiesta autonoma, da applicarsi cioè indipendentemente dal resto del requisito. L'altro partito, al contrario, sostiene che il requisito può essere superato anche se i box contenitori usati nella pagina hanno dimensioni fisse. Chi sostiene questo punto di vista ritiene che la frase citata precedentemente debba intendersi come una condizione determinata dal testo che la segue nell'enunciato: in altre parole, in base a quest'altra interpretazione, il requisito 12 richiederebbe semplicemente che i contenuti non si sovrappongano o diventino incomprensibili una volta che l'utente abbia modificato la dimensione della finestra del browser o la grandezza predefinita dei caratteri. Non richiederebbe, cioè, che i box contenitori modifichino le proprie dimensioni ad ogni variazione della larghezza della finestra del browser, come accade nell'impaginazione liquida.

Purtroppo non è possibile decidere in modo assoluto quale sia l'interpretazione corretta, perché entrambe possono essere derivate con una certa legittimità dal testo dell'enunciato. Quel che è certo è che, se i ridimensionamenti superano una certa soglia, è impossibile soddisfare il requisito 12, non importa se l'impaginazione sia fissa o sia liquida: infatti, caratteri troppo piccoli sono illeggibili mentre caratteri troppo grandi finiscono col nascondere quasi inevitabilmente parti del contenuto informativo della pagina, qualsiasi tipo di unità di misura venga adoperato.

In conclusione, il requisito 12, molto più complesso e dettagliato del punto di controllo delle WCAG a cui s'ispira, si dimostra, a differenza di quello, ambiguo e mal concepito, soprattutto perché il non fissare limiti per il ridimensionamento (come fa invece un analogo requisito delle WCAG 2.0) lo rende inapplicabile se inteso in senso letterale.

8. Mi rendo conto di farti ora una domanda a cui rispondere sinteticamente è difficile. Tuttavia, puoi sintetizzare in poche righe quale sia il senso delle differenze tra l'accessibilità definita dal W3C-WAI e l'accessibilità definita nella legge Stanca?

La differenza principale sta nel fatto che le raccomandazioni di accessibilità la cui applicazione è troppo legata a valutazioni soggettive sono state eliminate dai requisiti tecnici della legge 4/2004. Per esempio, il punto di controllo 14.1 delle WCAG 1.0, che raccomanda l'uso del linguaggio più chiaro e più semplice in relazione all'argomento trattato, non ha riscontri nei requisiti tecnici della legge italiana. Lo stesso dicasi del punto di controllo 4.1 delle WCAG 1.0, che richiede di marcare opportunamente i cambi di lingua all'interno del testo (cos'è, infatti, un cambio di lingua? Non è facile rispondere univocamente a questa domanda).

Non sono presenti anche molte delle raccomandazioni che, nelle WCAG 1.0, hanno priorità 3 e che sono legate più all'usabilità che alla mera possibilità di accedere ai contenuti. Al loro posto, la legge italiana ha inserito una serie di requisiti che fanno parte della cosiddetta verifica soggettiva, un livello ulteriore di accessibilità che non compete alle Pubbliche Amministrazioni, alle quali la legge richiede il rispetto dei soli ventidue requisiti inseriti nella cosiddetta verifica tecnica.

Una seconda differenza riguarda l'enunciato dei requisiti. Quelli della legge italiana sono espressi con una lingua che a me sembra particolarmente oscura e contorta, soprattutto in confronto al testo degli enunciati contenuti nello standard statunitense per l'accessibilità dei siti web (il paragrafo 1194.22 della Section 508), anch'esso derivato dalle WCAG 1.0.

Questa pagina è stata pubblicata il 24 ottobre 2007.