accesskey
Acquista il libro su Apogeonline
Google Memoria dello Spazio

Capitolo 15

Usare soluzioni temporanee

WCAG 1.0, linea guida 10. Usare soluzioni di accessibilità temporanee in modo che le tecnologie assistive e i browser meno recenti possano operare correttamente.

La linea guida 10 ha cinque punti di controllo: due di priorità 2 e tre di priorità 3.

“Until user agent...”

La linea guida 10 è composta, come la numero 7, da punti di controllo che cominciano tutti con la formula “until user agent”, cioè “finché i programmi utente”. Tale espressione indica che il punto di controllo che la contiene è di tipo transitorio. Va applicato, cioè, solo per ragioni di compatibilità all’indietro, non perché rappresenti un principio universale di sviluppo accessibile. Diciamo, per capirci, che si tratta di raccomandazioni con data di scadenza, anche se tale data è per lo più ignota.

Come chiarisce un’apposita definizione del glossario delle WCAG 1.0, i punti di controllo che contengono la frase "finché i programmi utente..." richiedono agli sviluppatori di contenuti di fornire un supporto aggiuntivo per l’accessibilità, finché la maggior parte dei programmi utente facilmente disponibili per il loro pubblico, non includerà le necessarie caratteristiche di accessibilità.

La raccomandazione lascia in una relativa incertezza gli sviluppatori: cosa vuol dire esattamente la “maggior parte dei programmi utente” (most user agents)? Il 50% +1 o il 99%? E poi browser e tecnologie assistive, come abbiamo visto nel Capitolo 2, sono davvero numerosi. È difficile tener traccia di tutti e ancor più difficile valutare se sono “facilmente reperibili” (readily available) per gli utenti oppure no: spesso gli ausili di buona qualità ci sono ma costano, dunque capita che un utente continui a usare una vecchia e superata versione di uno screen reader, piuttosto che acquistare la versione più recente e completa, dotata di migliore supporto per l’accessibilità (sappiamo, per esempio, di qualcuno che usa ancora la versione 3.71 di JAWS, quasi un pezzo di modernariato, mentre la società produttrice è ormai prossima a rilasciare la versione 9.0).

Alla fine, tocca agli sviluppatori assumersi la responsabilità di decidere fino a che punto garantire il supporto per tecnologie obsolete e dalle funzionalità limitate. È certo, del resto, che continua ad esservi una minoranza di utenti che, per le più svariate ragioni, utilizza programmi utente datati, bacati e poveri di funzionalità. È per questo che chi desidera sviluppare siti accessibili non dovrebbe mai trascurare di applicare il principio del potenziamento progressivo (si vedano in proposito i Capitoli 11 e 12), nei limiti in cui le risorse a disposizione e l’oggetto del sito lo consentono.

Va precisato, comunque, che esiste sul sito WAI-W3C, un documento intitolato User Agent Support for Accessibility collegamento esterno, cioè “Supporto dei programmi utente per l’accessibilità”, che dovrebbe servire proprio come riferimento ufficiale per conoscere lo stato di supporto di browser e tecnologie assistive per i requisiti di accessibilità provvisori. Purtroppo la sua consultazione non sarà di grande utilità, dal momento che il documento è clamorosamente indietro coi tempi, risalendo l’ultimo suo aggiornamento dichiarato all’8 dicembre 1999 (anche se viene annunciato un nuovo lavoro di test partito nel dicembre 2003, dei cui esiti però non risulta traccia).

Inutile negarlo: lo stato di provvisorietà mal si adatta alla formulazione di linee guida che devono durare nel tempo e che dovrebbero essere applicabili, nei limiti del possibile, senza troppe ambiguità. È per questa ragione che le raccomandazioni provvisorie non troveranno posto nelle WCAG 2.0, essendo state rese inutili dall’introduzione del concetto di baseline, in un primo tempo e poi, abbandonato questo, dall’introduzione del concetto di accessibility supported, sui quali ritorneremo nel Capitolo 20.

Inizio pagina

Salta inserzione pubblicitaria

Punto di controllo 10.1, priorità 2

Fino a quando i programmi utente non consentiranno agli utenti di impedire l’apertura di finestre multiple, evitare di far apparire pop-up o altre finestre e non cambiare la finestra corrente senza informare l’utente.

Si rivolge a: sviluppatori (tecnici del codice).

Finestre pop-up e accessibilità

Dal punto di vista tecnico, il succo di questo punto di controllo è la raccomandazione per gli sviluppatori di non usare in HTML o XHTML la combinazione attributo/valore che crea una nuova finestra (target="_blank").

I browser di più recente concezione – Firefox, Opera, Safari e persino l’ultimo Internet Explorer – consentono finalmente di bloccare l’apparizione delle finestre pop-up. Sembrerebbe perciò ormai prossima l’ora di non applicare più il punto di controllo 10.1, almeno per quanto riguarda il divieto di generare nuove finestre, lasciando all’utente la facoltà di impostare il comportamento del proprio browser nel modo che gli sembra più opportuno.

Tuttavia, come capita anche per altre raccomandazioni provvisorie delle WCAG 1.0, continua e continuerà a esistere la possibilità che vi siano utenti che adoperano tecnologie obsolete o non compatibili con il blocco delle finestre pop-up (Internet Explorer 6, per esempio, non permette il blocco, se non previa installazione del service pack 2 di Windows XP). Chi usa un browser testuale come Lynx, poi, non potrà in nessun caso accedere a finestre generate per mezzo di JavaScript: poco male, se si tratta di pubblicità non richiesta; molto male, se si tratta di contenuti importanti.

Insomma, se si vuole garantire la compatibilità all’indietro, è preferibile continuare a evitare la generazione di finestre multiple, oppure occorre usare il già citato metodo del potenziamento progressivo.

Non è, comunque, solo una questione di compatibilità all’indietro: la disseminazione dei contenuti su più finestre può essere un fenomeno disorientante, per certi tipi di utenti, anche se si viene opportunamente avvertiti. I navigatori alle prime armi e gli utilizzatori di screen reader sono i più esposti ad inconvenienti causati dall’apertura di nuove finestre, quali, per esempio, la perdita della cronologia e del funzionamento atteso del tasto Indietro (o Back) del browser.

A questo proposito, tuttavia, non tutte le testimonianze sono concordi: più di un non vedente, per esempio, ci ha confermato di non avere alcun problema nel gestire contenuti che si aprono in nuove finestre. Dipende molto – crediamo – dal livello di competenza dell’utilizzatore. Il comportamento più ragionevole è, tutto sommato, quello di ricorrere all’apertura di finestre pop-up solo in casi di reale utilità e previo avviso per l’utente.

Inizio pagina

Come avvisare dell’apertura di una nuova finestra

Un altro problema correlato all’applicazione del punto di controllo 10.1 riguarda il modo di avvertire l’utente dell’apertura di una nuova finestra. Tra i possibili sistemi c’è l’inserimento di un avviso all’interno dell’attributo title, come nell’esempio seguente:

Listato 15.1 Avviso di apertura di una nuova finestra tramite title (HTML e XHTML).

<a href="privacy.html" target="_blank"
title="[Il documento si aprirà in una nuova finestra]">

Informativa sulla privacy

</a>

Non è, in verità, una buona soluzione. Gli screen reader non leggono di solito i valori di title, a meno che l’utente non modifichi la configurazione iniziale (lo fanno solo i più esperti). Inoltre, se la lettura di title è alternativa al testo visibile dell’elemento, come avviene in JAWS, si rischia di perdere l’informazione principale per ottenere l’informazione accessoria. Per gli ipovedenti, poi, c’è il problema della scarsa usabilità dei tooltip, cioè i messaggini a comparsa su sfondo giallo, che sono il tipico sistema con cui i browser grafici notificano all’utente il contenuto di un attributo title.

Meglio, dunque, avvertire nel testo visibile della pagina che un collegamento aprirà una nuova finestra. Si può usare al posto di un avviso testuale anche un simbolo grafico, purché sia sufficientemente grande e comprensibile e purché, ovviamente, sia associato a un opportuno testo alternativo, a beneficio di chi non è in grado di vedere le immagini.

Listato 15.2 Avviso di apertura di una nuova finestra nel testo visibile del documento.

<a href="privacy.html" target="_blank">

Informativa sulla privacy [nuova finestra]

</a>

Listato 15.3 Avviso di apertura di una nuova finestra mediante un simbolo grafico.

<a href="privacy.html" target="_blank">

Informativa sulla privacy

<img src="nuova_finestra.png" width="20" height="15"
alt="[Il documento si aprirà in una nuova finestra]">

</a>

Va da sé che l’uso dell’attributo target impone la scelta della DTD transitional. Se si vuole preservare l’uso della DTD strict, occorre servirsi di un altro metodo, come per esempio quello mostrato nei Listati 11.7 e 11.8, in cui sia l’apertura di una nuova finestra sia il messaggio di avviso sono implementati tramite JavaScript non invasivo.

Inizio pagina

Punto di controllo 10.2, priorità 2

Fino a quando i programmi utente non supporteranno l’esplicita associazione tra etichette e controlli di modulo, per tutti i controlli di modulo che hanno etichette associate in modo implicito, garantire che l’etichetta sia posizionata correttamente.

Si rivolge a: sviluppatori (tecnici del codice).

Associazione implicita tra etichette e campi modulo

L’elemento per marcare le etichette dei controlli di modulo è LABEL. Quest’elemento può essere associato ad un unico controllo di modulo ed ha la duplice funzione di spiegare a cosa serve il controllo associato e di trasferirgli il focus, se selezionato.

L’associazione tra un’etichetta e il relativo controllo di modulo può essere implicita o esplicita. Esamineremo quest’ultimo tipo di associazione nel commento al punto di controllo 12.4. Consideriamo ora, invece, il meccanismo dell’associazione implicita, riportando la spiegazione contenuta nelle specifiche HTML 4.01:

Per associare implicitamente un’etichetta con un altro controllo, l’elemento del controllo deve essere all’interno del contenuto dell’elemento LABEL. In tal caso, LABEL può contenere un unico elemento controllo. Il testo dell’etichetta può essere posizionato prima o dopo il controllo associato.

L’esempio seguente mostra un’associazione implicita tra due etichette e due campi di immissione del testo in un documento HTML.

Listato 15.4 Associazione implicita tra etichette e campi modulo.

<form action="..." method="post">
<p>

<label>
Nome
<input type="text" name="nome">
</label>

<label>
Cognome
<input type="text" name="cognome">
</label>

</p>
</form>

Le Specifiche HTML 4.01 rilevano che la tecnica illustrata nell’esempio non può essere utilizzata in una tabella a scopo d’impaginazione, in cui l’etichetta si trovi in una cella e il campo modulo associato in un’altra. Ciò perché, come spiegato prima, l’associazione implicita richiede che l’elemento INPUT sia contenuto all’interno dell’elemento LABEL che lo richiama.

Va precisato che gli screen reader oggi in uso supportano adeguatamente entrambi i tipi di associazione – implicita ed esplicita – tra elementi LABEL e relativi controlli di modulo.

Inizio pagina

Salta inserzione pubblicitaria

Punto di controllo 10.3, priorità 3

Fino a quando i programmi utente (comprese le tecnologie assistive) non riprodurranno correttamente i testi affiancati, fornire un’alternativa testuale lineare (sulla pagina corrente o su un’altra pagina) per tutte le tabelle che dispongono il testo su colonne parallele con parole che vanno a capo.

Si rivolge a: sviluppatori (tecnici del codice).

Testi affiancati su più colonne

In primo luogo è necessario comprendere bene la situazione a cui fa riferimento questo punto di controllo: la situazione è quella di una tabella costituita da due o più colonne di testo affiancate, in cui almeno una colonna abbia il testo che va a capo su più righe.

Il paragrafo 5.3 delle Tecniche HTML per le WCAG 1.0 spiega:

Le tabelle a scopo d’impaginazione in cui il testo nelle celle va a capo pongono problemi agli screen reader più vecchi che non interpretano il codice HTML o ai browser che non consentono di navigare singole celle di tabella. Questi screen reader scorrono l’intera pagina da un capo all’altro, leggendo le stringhe di testo su una stessa riga, appartenenti a differenti colonne, come se costituissero un unico periodo.

Per esempio, se una tabella è resa sullo schermo in questo modo:

C’è un 30% di probabilità che questa
mattina vi siano temporali, ma dovrebbero
cessare prima del fine settimana.
Le lezioni all’Università del Wisconsin
riprenderanno il 3 Settembre.

Potrebbe essere letta da uno screen reader come:

“C’è un 30% di probabilità che questa Le lezioni all’Università del Wisconsin mattina vi siano temporali, ma dovrebbero riprenderanno il 3 Settembre cessare prima del fine settimana.”

Il 10.3 è uno dei pochissimi punti di controllo provvisori per il quale esiste qualche informazione sullo stato di supporto da parte dei programmi utente nel già citato documento User Agent Support for Accessibility. Ecco il testo in questione:

Status: Home Page Reader di IBM in combinazione con Netscape Navigator (4.5, Win98) e JAWS di Henter Joyce in combinazione con Microsoft Internet Explorer (4.0 e successivi, Win98) sono esempi di un browser e di una tecnologia assistiva che, lavorando in combinazione, possono linearizzare una tabella. Opera (3.6, Win 98) consente agli utenti di linearizzare le tabelle. Lynx (2.81, Unix) riproduce le tabelle per riga. Gateway di Silas e altri strumenti sviluppati dal Gruppo di Lavoro ER [ER-IG] permettono di linearizzare le tabelle. Tuttavia, soltanto Microsoft Internet Explorer (4.0 e superiori, Win98) con HelpDB e WWW con EmacsSpeak permettono a un utente di navigare all’interno e tra le celle di una tabella.

Come è facile capire, le informazioni contenute nel brano qui citato si riferiscono a programmi utente di fine secolo scorso. Negli ultimi anni la situazione è nettamente migliorata: JAWS e Window-Eyes, per esempio, che sono gli screen reader attualmente più usati, consentono qualsiasi tipo di navigazione all’interno delle tabelle, compresa la lettura accessibile di tabelle di dati opportunamente marcate. In realtà, non ci sono noti né browser né tecnologie assistive, tra quelli attualmente in uso, che presentino il difetto di interpretazione delle tabelle, per il quale il punto di controllo 10.3 intendeva fornire un’alternativa accessibile. Tuttavia, se proprio si vuole rispettare questo punto di controllo, è necessario che per ogni tabella con testo su più colonne affiancate sia fornita la versione linearizzata. Questa può essere presentata su una pagina differente, purché il collegamento che la referenzia sia posto in una posizione ben visibile all’interno del documento che contiene la tabella di riferimento (possibilmente prima della tabella).

Inizio pagina

Come linearizzare una tabella di dati

Abbiamo già spiegato nel commento al punto di controllo 5.3 come realizzare la versione linearizzata di una tabella d’impaginazione. Per una tabella di dati le cose sono un po’ diverse: non basta riportare in sequenza il contenuto di ogni cella a partire dalla prima riga.

Per capire la differenza, consideriamo una tipica tabella di dati, come un calendario mensile, con i nomi dei giorni della settimana nella riga d’intestazione e i numeri dei giorni nelle sottostanti righe di dati. Linearizzandolo nel modo in cui si linearizza una tabella d’impaginazione, avremmo il seguente risultato:

Lunedì, Martedì, Mercoledì, Giovedì, Venerdì, Sabato, Domenica, 1, 2, 3, 4, 5, 6, …, 27, 28, 29, 30, 31.

Si ottiene, cioè, un elenco di nomi di giorni e di numeri sostanzialmente inutile. Perché il testo linearizzato di una tabella di dati abbia significato è necessario, infatti, accoppiare il contenuto di ogni cella di dati con il contenuto della sua cella d’intestazione (o delle sue celle d’intestazione, se ne ha più di una). Applicando questa regola, per esempio, al calendario mensile di maggio 2007, otteniamo questo nuovo risultato, che ha pienamente senso:

Martedì 1, Mercoledì 2, Giovedì 3, Venerdì 4, Sabato 5, Domenica 6, Lunedì 7 ecc.

Considerando il procedimento dal punto di vista del codice di marcatura, si tratta di prelevare in sequenza, secondo lo stesso ordine indicato nel commento al punto di controllo 5.3 (Capitolo 8), il contenuto di ogni elemento TD, facendolo precedere dal contenuto di ogni TH o TD che gli sia associato come cella d’intestazione.

Inizio pagina

Punto di controllo 10.4, priorità 3

Fino a quando i programmi utente non gestiranno correttamente i controlli vuoti, inserire dei caratteri segnaposto predefiniti nei campi in cui è possibile immettere testo.

Si rivolge a: sviluppatori (tecnici del codice).

Caratteri segnaposto nei campi di immissione testo

Il punto di controllo 10.4 fa riferimento agli elementi INPUT e TEXTAREA. Esempi classici di applicazione di questo requisito sono i campi di ricerca che contengono un testo predefinito, come nel seguente frammento di codice, che fa comparire nella casella di immissione la stringa “Testo segnaposto”:

Listato 15.5 Codice HTML per l’inserimento di un testo segnaposto in un campo INPUT.

<form action="..." method="get">
<p>

<label for="ricerca">Cerca nel sito:</label>

<input id="ricerca" type="text" size="20"
value="Testo segnaposto">

<input type="submit" value="Vai">

</p>
</form>

Anche per questo punto di controllo, come già per il precedente, c’è una nota nel documento del W3C intitolato User Agent Support for Accessibility. Vi si dice brevemente:

1. i browser più datati (Netscape 2.0?) non consentivano agli utenti di navigare all’interno dei controlli di modulo;

2. le tecnologie assistive più datate, nel tentativo di superare questo problema, consentirebbero di navigare solo all’interno di controlli di modulo con contenuto.

La nota, di per sé piuttosto vaga, fa riferimento a tecnologie che erano già obsolete nel 1999. Per quanto riguarda il presente, non ci è noto alcun programma utente che impedisca di inserire testo in un campo modulo vuoto, sia esso INPUT o TEXTAREA. Suggeriamo perciò agli sviluppatori di non preoccuparsi di questo punto di controllo: non applicarlo non creerà alcuna perdita di accessibilità; è la sua applicazione, piuttosto, che può creare problemi agli utenti.

Leggiamo in proposito ciò che ha scritto Joe Clark nel Capitolo 12 del suo già citato Building Accessible Websites collegamento esterno:

Come persona non disabile che usa Internet da sempre, come dattilografo veloce ed esperto di tutte le scorciatoie da tastiera di largo uso, persino io spesso devo combattere per cancellare fino all’ultimo carattere all’interno di un campo. So tutto delle sequenze come Seleziona tutto e Cancella, ma la metà delle volte sbaglio il comando Seleziona tutto (selezionando ogni cosa nella finestra del browser) oppure tento di selezionare il testo col mouse e faccio clic invece il pulsante adiacente, oppure cancello tutto meno un carattere. Nient’altro che problemi. E io non sono cieco né ho impedimenti nel maneggiare tastiera e mouse. Immaginate che fastidio sia per chi fa parte di quei gruppi.

Se proprio si vuole applicare il punto di controllo 10.4, magari perché si sta eseguendo un contratto che richiede il rispetto del livello tripla A delle WCAG 1.0, la cosa migliore è servirsi di un JavaScript che cancelli automaticamente il testo segnaposto nel momento in cui il campo modulo che lo contiene riceve il focus. Riportiamo di seguito un breve script che, se inserito nell’elemento INPUT dell’esempio precedente, è in grado di cancellare la stringa “Testo segnaposto” non appena il campo viene attivato, senza alcun intervento da parte dell’utente. Naturalmente non funzionerà nei browser che non supportano JavaScript nativamente (come Lynx) né nei browser in cui le funzionalità dinamiche sono state volutamente disabilitate.

Listato 15.6 Script per cancellare il contenuto di un campo al ricevimento del focus.

onfocus="if (this.value=='Testo segnaposto') this.value='';"

Inizio pagina

Punto di controllo 10.5, priorità 3

Fino a quando i programmi utente (comprese le tecnologie assistive) non riprodurranno i link adiacenti in modo distinto, includere tra i link adiacenti caratteri stampabili (delimitati da spazi) che non fanno parte di un collegamento.

Si rivolge a: sviluppatori (tecnici del codice).

Caratteri stampabili e link adiacenti

Il punto di controllo 10.5 raccomanda di separare i collegamenti ipertestuali che verrebbero riprodotti l’uno di seguito all’altro sulla stessa riga, inserendo tra loro almeno un carattere stampabile circondato da spazi. Ecco un esempio di applicazione del requisito:

Listato 15.7 Collegamenti separati da un carattere stampabile circondato da spazi.

<p><a href="home.html">Prima pagina</a> | <a

href="chis.html">Chi siamo</a> | <a

href="prod.html">Prodotti</a> | <a

href="cont.html">Contatti</a></p>

A corredo di questo punto di controllo, il documento User Agent Support for Accessibility rimanda addirittura ad una serie di test di controllo, effettuati da Charles McCathieNevile a Novembre del 1999. I test sono raggruppati in un documento intitolato Test Case for grouping of Links and whitespace collegamento esterno.

Il codice sottoposto a test comprendeva cinque serie di link adiacenti, alcuni privi di separazione, altri separati con differenti modalità. Le prove furono eseguite con Home Page Reader 2.5 su Windows 98, con Amaya 2.2 su Linux RedHat 6.0, con Lynx 2.8 e Netscape 4.7, anch’essi su Linux RedHat 6.0.

I due test più importanti, cioè quelli eseguiti con strumenti usati da utenti disabili (il browser vocale Home Page Reader e il browser testuale Lynx), diedero come esito che tutte e cinque le combinazioni di link adiacenti risultavano usabili. Qualche problema emerse invece dai test fatti con Amaya e Netscape 4.7. Ma il primo è un browser puramente sperimentale, prodotto dallo stesso W3C e oggi arrivato a un livello di sviluppo molto più avanzato di quello raggiunto nel 1999 (la versione corrente è la 9.55, scaricabile da http://www.w3.org/Amaya/ collegamento esterno). Il secondo è invece un Netscape della serie 4, la peggior serie di browser di tutti i tempi, affetta da bachi di ogni tipo e gravità: una serie, per fortuna, in via di definitiva scomparsa (anche se dura a morire: si veda il paragrafo Netscape nel Capitolo 2).

Possiamo dire, in conclusione, che ciò che raccomanda il punto di controllo 10.5 non è oggi essenziale per garantire l’accessibilità, almeno per quanto riguarda i moderni screen reader e browser testuali.

Ciò che invece è importante sottolineare è la necessità che i link adiacenti siano sufficientemente spaziati, sia in orizzontale sia in verticale: solo così gli utenti affetti da problemi motori e gli ipovedenti potranno attivare un link senza correre il rischio di premere per errore quello adiacente. I caratteri stampabili circondati da spazi e interposti tra due link adiacenti svolgono perciò una funzione in ogni caso utile per l’accessibilità: quella di aumentare la distanza tra due collegamenti. Lo stesso scopo si può ottenere però con un uso accorto dei fogli di stile, impostando per esempio un’adeguata grandezza dei caratteri e inserendo valori discreti delle proprietà padding e line-height.

Inizio pagina

Salta inserzione pubblicitaria

Rendere invisibili in modalità grafica i caratteri di separazione

È possibile applicare il punto di controllo 10.5 e allo stesso tempo formattare gli spazi con i CSS, facendo in modo che i caratteri stampabili non appaiano in modalità grafica, ma solo in modalità testuale (per esempio con Lynx o con un browser grafico con il supporto per i fogli di stile disattivato). Il Listato 15.8 illustra come rendere invisibili i caratteri stampabili di separazione a chi navighi con un comune browser grafico. Gli elementi a cui è applicata la classe no vengono posizionati in un luogo che si trova diecimila pixel in alto a sinistra rispetto alla pagina visibile. Ciò fa in modo che continuino a esistere per la navigazione con uno screen reader o in modalità testuale, mentre sono assolutamente invisibili per chi naviga con un qualsiasi browser grafico recente, dotato di supporto attivo per i fogli di stile.

Listato 15.8 Carattere stampabile e spazi di separazione tra link resi invisibili tramite CSS.

/* impostazione dello stile CSS */

.no {
position: absolute;
top: -10000px;
left: -10000px;
}

. . . . . .

<p><a href="home.html">Home page</a><span class="no"> | </span><a

href="chis.html">Chi siamo</a><span class="no"> | </span><a

href="prod.html">Prodotti</a><span class="no"> | </span><a

href="cont.html">Contatti</a></p>

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.