accesskey
Acquista il libro su Apogeonline
Google Memoria dello Spazio

Capitolo 18

Fornire chiari meccanismi di navigazione

WCAG 1.0, linea guida 13. Fornire chiari e coerenti meccanismi di navigazione – informazioni di orientamento, barre di navigazione, una mappa del sito ecc. – per aumentare le probabilità che una persona trovi ciò che sta cercando in un sito.

La linea guida 13 ha dieci punti di controllo: quattro di priorità 2 e sei di priorità 3.

La spiegazione che correda questa linea guida dice:

Meccanismi di navigazione chiari e coerenti sono importanti per le persone con disabilità cognitive o cecità, e vanno a beneficio di tutti gli utenti.

Cosa s’intende dunque per meccanismi di navigazione? Riportiamo di seguito la definizione contenuta nel glossario delle WCAG 1.0 collegamento esterno:

Un meccanismo di navigazione è qualsiasi strumento tramite il quale un utente può navigare una pagina o un sito. Tipici meccanismi sono:

Punto di controllo 13.1, priorità 2

Identificare chiaramente la destinazione di ogni collegamento.

Si rivolge a: sviluppatori (tecnici del codice).

Mai più “clicca qui”!

Il paragrafo 6.1 Link text collegamento esterno delle Tecniche HTML per le WCAG 1.0 fornisce una serie di utili suggerimenti, per rendere accessibili i collegamenti ipertestuali anche a utenti che navigano in modalità non visuale. Li riportiamo di seguito in traduzione italiana, con l’esclusione di alcune righe non essenziali.

Un buon testo usato come collegamento non dovrebbe essere troppo generico; non usate “clicca qui”. Non soltanto si tratta di una frase dipendente dal dispositivo (presume uno strumento di puntamento), ma non dice nulla su ciò che si troverà se si decide di seguire il collegamento. Invece di “clicca qui”, il testo di un link dovrebbe indicare la natura della destinazione del collegamento, come in “maggiori informazioni sui leoni marini” o in “versione solo-testo di questa pagina”. […]

In aggiunta a un testo del collegamento che sia esplicativo, gli sviluppatori di contenuti possono specificare un valore dell’attributo title che descriva in modo chiaro e accurato la destinazione del collegamento.

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à.

Se due o più collegamenti si riferiscono a destinazioni differenti ma condividono lo stesso testo visibile, distinguete tra loro i collegamenti specificando un valore differente dell’attributo title per ciascun elemento A.

Gli “utenti acustici” – non vedenti, persone con deficit della vista o che stanno usando dispositivi con schermo piccolo o privi di schermo – non possono scorrere rapidamente la pagina con i loro occhi. Per ottenere una panoramica di una pagina o per trovare velocemente un link, questi utenti devono spesso tabulare da un link al successivo o devono passare in rassegna un elenco dei collegamenti disponibili sulla pagina.

Pertanto, nel caso di collegamenti correlati, includete informazioni introduttive nel primo collegamento, poi informazioni distintive nei link successivi. Ciò fornirà informazioni contestuali agli utenti che li leggono in sequenza.

Possiamo condensare il brano precedente in due raccomandazioni per l’accessibilità, che sono, in ordine d’importanza:

  1. usare per i collegamenti ipertestuali testi che descrivano chiaramente la destinazione e che abbiano significato anche se letti fuori contesto;
  2. associare con coerenza testi dei link e documenti collegati (testi uguali dovrebbero rimandare alla medesima risorsa, testi differenti a risorse differenti).

Inizio pagina

Salta inserzione pubblicitaria

Mappe ragionate al posto dei link nel testo

In Progettare e scrivere per Internet collegamento esterno (McGraw-Hill, Milano 2005), Giovanni Acerboni suggerisce una soluzione che rappresenta, indirettamente, un modo per soddisfare il punto di controllo 13.1 delle WCAG 1.0. Nel paragrafo 7.10 (Le pagine pertinenti), l’autore scrive:

[...] inserire dei link nel testo significa suggerire al navigatore che il testo può essere abbandonato in quel punto, cioè che tutto ciò che segue può essere “saltato”. Questo suggerimento svaluta il contenuto della pagina corrente e, di conseguenza, il senso del rapporto di questa pagina con le pagine a essa correlate. Non solo. I link interni al testo (link embedded), per il fatto stesso di possedere un formato diverso da quello delle altre parole, conferiscono alle parole su cui sono applicati un’evidenza superiore a quella che dovrebbero avere, e dunque suggeriscono che le pagine a cui rimandano abbiano un’importanza maggiore della pagina corrente. [...] Per queste ragioni, l’autore che intende valorizzare (e far apprezzare) il proprio lavoro deve inserire i link alle pagine pertinenti nella mappa ragionata (...). La mappa ragionata è lo spazio nel quale i link hanno la massima evidenza (molto maggiore di quella che avrebbero all’interno del testo). Inoltre, in questo spazio, i link possono essere definiti in modo che il navigatore capisca dove lo porta il clic. Ciò che non può capire da un link nel testo. Non si è riflettuto abbastanza sul fatto che i link embedded vengono applicati su una parola dopo che l’autore abbia scritto il testo: prima si scrive il testo e poi si decide quali parole debbano essere linkate. Questo procedimento toglie all’autore la possibilità di definire il link in modo autonomo dalla struttura linguistica della frase. La definizione dei link embedded coincide con il ruolo che la parola su cui viene applicato ha nella struttura della frase e, pertanto, molto raramente il navigatore comprende chiaramente perché l’autore lo inviti a cliccare su quella parola, e che cosa contenga la pagina di destinazione.

Le considerazioni di Acerboni sono a nostro parere ampiamente condivisibili. Se dei link sono inseriti in un testo discorsivo, le parole su cui sono applicati servono innanzitutto a rendere coerenti e comprensibili le frasi di cui fanno parte. Tale scopo può non coincidere affatto con quello di rendere il testo dei link autoesplicativo, secondo quanto richiede il punto di controllo 13.1.

Un esempio aiuterà a capire meglio il concetto. La Figura 18.1 mostra un brano tratto dal blog di Beppe Grillo collegamento esterno. Contiene tre link che, se letti fuori contesto, non permettono di capire la destinazione a cui ciascuno punta. Saltando dall’uno all’altro con uno screen reader, la sintesi vocale leggerebbe in successione: “il lavoro è peggio dell’Aids”, “sette milioni di euro” e “consigliere di amministrazione”. Troppo poco, per capire su quali siti si trovano e di cosa parlano le tre pagine a cui i tre link rimandano.

Figura 18.1. Un esempio di link non autoesplicativi (dal blog di Beppe Grillo, post del 21/1/2007).

Dal punto di vista dell’accessibilità, e per le ragioni descritte da Acerboni nel brano citato dal suo libro, sarebbe preferibile che quei tre collegamenti fossero eliminati dal testo discorsivo e messi in una mappa ragionata, cioè in uno spazio attiguo all’articolo e fatto apposta per contenere collegamenti ad altre risorse. In un tale spazio dedicato, è molto più facile per gli autori scrivere testi dei link che ne rendano immediatamente chiara la destinazione.

La Figura 18.2 mostra l’applicazione di quest’idea al brano tratto dal blog di Beppe Grillo mostrato nella figura precedente.

Figura 18.2. I link presenti in Figura 18.1 sono stati eliminati dal testo discorsivo e spostati nella mappa ragionata sulla destra. Ciascuno di essi è stato poi modificato in modo da renderlo autoesplicativo e perciò utilizzabile anche fuori contesto.

[Inizio approfondimento] Rimandi numerati

Volendo rendere visibile la relazione tra i link della mappa ragionata e i punti precisi del testo da cui quei link dipendono semanticamente, si possono aggiungere dei rimandi numerati dal testo alla mappa: nel brano in Figura 18.2 si potrebbe aggiungere, ad esempio, un numero 1 dopo la frase “il lavoro è peggio dell’AIDS”, come rimando al primo link della mappa ragionata, un numero 2 dopo il frammento “sette milioni di euro”, e così via, ponendo naturalmente gli stessi numeri accanto ai corrispondenti link della mappa. Il sistema dei rimandi a note è più adatto, però, ai testi tecnici e scientifici che a quelli meramente discorsivi, dal momento che crea un certo appensantimento della lettura. [Fine approfondimento]

È importante precisare che il sistema delle mappe ragionate è già largamente adoperato, soprattutto dai siti informativi. La Figura 18.3 mostra un esempio tratto da Repubblica.it. Alla destra dell’articolo, si può notare un riquadro intitolato “Link correlati”, che contiene i collegamenti ad altri articoli di argomento affine. Il testo dei collegamenti corrisponde al titolo degli articoli e rende in genere comprensibile la destinazione dei link anche quando letti fuori contesto. Purtroppo la soluzione usata da Repubblica.it ha il grave difetto di riportare sempre, nella mappa ragionata, anche un collegamento che rimanda all’articolo corrente; a volte, anzi, è il solo presente nella mappa. L’“autolink”, cioè il collegamento che rimanda alla pagina corrente, è una pessima soluzione dal punto di vista dell’usabilità: nella migliore delle ipotesi fa perdere tempo, nella peggiore disorienta l’utente.

Figura 18.3. Il box dei link correlati di Repubblica.it è un’applicazione del criterio delle mappe ragionate.

L’errore dell’autolink non compare, invece, nel sito de Le scienze collegamento esterno, dove in molti articoli è presente una mappa ragionata, inserita in un riquadro intitolato “Approfondimenti”, nel quale sono presenti collegamenti ad articoli di argomento affine.

Figura 18.4. La mappa ragionata nel sito de “Le scienze” (30/1/2007).

Inizio pagina

Il grande incompiuto: l’attributo title

Il consiglio di usare l’attributo title per sopperire a situazioni in cui il testo visibile dei collegamenti non è sufficiente è in teoria un ottimo suggerimento; nella pratica – purtroppo – lo è meno. Ciò perché il modo in cui browser e tecnologie assistive rendono i contenuti di title è a dir poco inadeguato.

Per un’analisi approfondita dei problemi della resa di title in congiunzione con l’elemento A, rimandiamo il lettore all’ottimo studio di Steve Faulkner, pubblicato su Vision Australia e consultabile all’indirizzo http://www.sf.id.au/ozewai/ collegamento esterno. Sintetizzando, le questioni sono essenzialmente tre:

Per tali ragioni, l’uso di title, almeno finché non saranno cambiate le regole del supporto da parte dei programmi utente, non è una scelta di accessibilità efficace. È di gran lunga preferibile inserire le informazioni distintive nel testo visibile (e ascoltabile) dei collegamenti. Esistono del resto numerose tecniche, messe a punto negli anni dagli sviluppatori, per incorporare informazioni complementari nei documenti in una forma più accessibile di quella consentita dall’attributo title: per esempio, messaggi ad alta visibilità, che vengono fatti comparire al passaggio del mouse su zone sensibili, grazie all’azione combinata di script e fogli di stile; o, anche, informazioni nascoste in modalità grafica, che sono però leggibili dagli screen reader e da chi usa browser senza supporto per i fogli di stile.

Figura 18.5. Un tooltip generato dal passaggio del mouse su un collegamento che contiene un attributo title. Il testo appare troncato perché si estende oltre l’area resa visibile dall’ingranditore di schermo.

Inizio pagina

Punto di controllo 13.2, priorità 2

Fornire metadati per aggiungere informazioni semantiche a pagine e siti.

Si rivolge a: autori, sviluppatori (tecnici del codice).

Metadati. Uso accessibile dell’elemento TITLE

Il prefisso di origine greca “meta-”, attaccato alla parola “dato”, forma una nuova parola, “metadato”, che ha il significato di “ciò che va al di là del dato”. Più specificamente, i metadati sono in HTML delle informazioni sulle informazioni: detto in parole più semplici, mentre i dati comuni, come immagini e testi, formano il contenuto di un documento, i metadati sono informazioni sul contenitore, cioè sul documento. Questo tipo di informazioni può svolgere una preziosa funzione di orientamento per l’utente, incrementando così l’accessibilità complessiva dei documenti.

HTML e altri linguaggi di marcatura del W3C consentono di incorporare in un documento diversi tipi di metadati. Il primo, e probabilmente il più importante, è l’elemento TITLE, da non confondere con l’attributo title di cui abbiamo parlato nel commento al punto di controllo 13.1.

L’elemento TITLE, come indica il nome, ha la funzione di dare un titolo al documento in cui è inserito. Il suo contenuto appare sulla barra del titolo dei browser ed è la prima informazione che gli screen reader leggono all’ascoltatore, nel caricare un nuovo documento HTML o XHTML. Usare un testo significativo per l’elemento TITLE è dunque un’essenziale raccomandazione di accessibilità. Andrebbero evitati, però, titoli troppo lunghi, inutili formule di benvenuto e l’uso di caratteri decorativi insieme al testo informativo.

Il Listato 18.1 presenta alcuni esempi di uso di TITLE, riferiti alla pagina “Chi siamo” di un ipotetico sito web, dedicato ad un’altrettanto ipotetica marca di birra. I primi quattro esempi illustrano usi da evitare, l’ultimo un uso corretto (l’elemento TITLE ideale è una descrizione sintetica e precisa del contenuto).

Listato 18.1. Cinque variazioni sul tema nell’uso di TITLE.

A. <title>Eccoti finalmente giunto nel sito dedicato alla migliore birra del mondo, la famosa birra Zucconi!</title>

B. <title>Benvenuto nel sito della birra Zucconi! Questa è la pagina "Chi siamo"</title>

C. <title>..::--++ Birra Zucconi, ecco chi siamo ++--::..</title>

D. <title>Chi siamo</title>

E. <title>Birra Zucconi. Chi siamo</title>

L’esempio A non va bene perché il testo è troppo lungo: su un browser grafico il titolo rischia di apparire troncato, se visualizzato su uno schermo a bassa risoluzione (la barra del titolo può contenere un’unica riga di testo); nell’ascolto con un sintetizzatore vocale, soprattutto se il titolo lungo si ripete su ogni pagina, si crea nell’ascoltatore una condizione di noia e di fastidio. Per di più, il titolo nell’esempio A è poco informativo, perché non dice all’utente che si trova sulla pagina “Chi siamo”, ma fa riferimento solo alle qualità della birra a cui è dedicato il sito.

Anche il titolo nell’esempio B, benché sia più breve di quello precedente, ha qualcosa che non va. Qui l’informazione relativa alla pagina “Chi siamo” viene fornita, ma solo alla fine di una formula di benvenuto che, se ripetuta su ogni pagina del sito, risulta fastidiosa come il testo dell’esempio A. Il benvenuto è simpatico la prima volta che lo si ascolta: dalla seconda pagina o dalla seconda visita in poi diventa un fastidio di cui si farebbe volentieri a meno.

Figura 18.6. Alla risoluzione di 640×480, il titolo nell’esempio A appare troncato (il browser usato è Safari su Mac OS X).

L’esempio C non presenta problemi per l’utente vedente, ma solo per chi usa uno screen reader. L’arte ASCII con cui è “guarnito” il titolo produce infatti la lettura di una lunga e incomprensibile serie di simboli da parte della voce sintetica. Ecco come sarebbe letto quel titolo, se inserito realmente in una pagina web: “Punto-punto-due punti-due punti-trattino-trattino-più-più Birra Zucconi, ecco chi siamo più-più-trattino-trattino-due punti- due punti-punto-punto”. Meglio evitare…

L’esempio D pecca per eccesso di sintesi. Solo “Chi siamo” è troppo poco, per chi si orienta unicamente con l’udito. Manca l’informazione essenziale: in che sito ci troviamo? L’utente, infatti, potrebbe essere arrivato a quella pagina provenendo direttamente da un sito esterno, per esempio da un motore di ricerca. Tralasciare di inserire nel titolo di un documento il nome del sito a cui appartiene è un po’ come scrivere il proprio indirizzo indicando solo la via e il numero civico, senza specificare la città.

L’esempio E è l’unico veramente valido: l’informazione è la più sintetica possibile, ma è allo stesso tempo precisa e completa.

Riassumendo, le due caratteristiche essenziali di un elemento TITLE ben compilato sono la sintesi e la precisione: va usato il minor numero possibile di parole, ma avendo cura di inserire le informazioni indispensabili a permettere all’utente di orientarsi con sicurezza.

[Inizio approfondimento] Integrazione dei contenuti di TITLE e di H1

Nel dare un contenuto all’elemento TITLE, è buona pratica cercare di renderlo complementare al testo che appare nel titolo, o nei titoli, di primo livello del documento (elemento o elementi H1).

Poniamo il caso di avere una pagina web che spieghi come compilare il modello F24, usato da molti contribuenti per pagare le tasse. Nel corpo del documento abbiamo un elemento H1, che contiene il testo “Istruzioni per la compilazione del modello F24”. È un buon titolo, sintetico e preciso, che potrebbe essere usato anche come contenuto di TITLE; ma ha senso duplicare la stessa informazione, costringendo chi usa uno screen reader ad ascoltarla due volte di seguito? Pensiamo proprio di no. È utile, invece, differenziare le informazioni, cercando di rendere TITLE e H1 complementari piuttosto che ridondanti. Nel caso della pagina sul modello F24, l’elemento TITLE potrebbe perciò limitarsi a fornire informazioni sul sito e sulla sezione, per esempio in questo modo: “Studio Tremontini. Area modelli: F24”. La sintesi e la precisione sono conservate, ma non c’è sovrapposizione col contenuto di H1.

Il problema si pone in termini un po’ diversi, se nel corpo del documento non c’è un titolo dominante sugli altri, ma vi sono più titoli di primo livello coordinati. Prendiamo il caso di una pagina web che contenga l’originale inglese e la traduzione italiana della celeberrima poesia “O Capitano! Mio Capitano!” del poeta americano Walt Whitman. In una simile pagina, sarebbe adeguato avere due elementi H1, uno contenente il titolo in inglese e l’altro il titolo in italiano della poesia. Cosa scriveremo allora nell’elemento TITLE? Il Listato 18.2 propone come soluzione un testo che riassume il contenuto generale del documento, con riferimento a entrambi gli H1.

Listato 18.2. Uso di TITLE quando in un documento HTML vi è più di un titolo principale.

<title>Poeti dell'Ottocento.
Walt Whitman, "O capitano! Mio capitano!"
in inglese e in italiano</title>

......

<div lang="en">

<h1>O Captain! My Captain</h1>

<p>O Captain! my Captain! our fearful trip is done;<br>
The ship has weather'd every rack, the prize we sought is won;<br>

......

</div>

<div lang="it">

<h1>O Capitano! Mio Capitano</h1>

<p>O Capitano! mio Capitano! il nostro viaggio tremendo è finito,<br>

La nave ha superato ogni tempesta, l'ambito premio è vinto,<br>

......

</div>

[Fine approfondimento]

Inizio pagina

Metadati. L’elemento ADDRESS

Un tipo di metadato usato per lo più in contesti tecnici e scientifici è l’elemento ADDRESS. Messo generalmente alla fine di un documento HTML o XHTML, il suo scopo è fornire informazioni sulla persona, il gruppo o l’ente che ha prodotto, gestisce e aggiorna il documento in cui è inserito. ADDRESS dovrebbe contenere anche la data dell’ultimo aggiornamento e i recapiti per contattare chi si occupa della manutenzione. Come si può facilmente capire, non si tratta di informazioni secondarie o inutili: l’uso e l’attenta compilazione dell’elemento ADDRESS aumentano le possibilità che gli utenti usino con soddisfazione e profitto le risorse contenute in un documento.

Riportiamo di seguito un esempio d’uso di ADDRESS, tratto dalla realtà del Web: le informazioni di contatto, alla fine della pagina-indice sul linguaggio RDF, nel sito del W3C.

Listato 18.3. Uso di ADDRESS in un documento XHTML del W3C.

<address class="footer">

<a href="../People/Ivan">Ivan Herman</a> &lt;ivan@w3.org&gt;, (W3C)

Semantic Web Activity Lead,<br />

<a href="mailto:swick@w3.org">Ralph Swick</a> &lt;swick@w3.org&gt; (W3C)

SWBPD Team Contact,<br />

<a href="mailto:danbri@w3.org">Dan Brickley</a> (W3C) Semantic Web Interest

Group Chair<br />

$Id: Overview.html,v 1.179 2006/10/27 12:34:36 jigsaw Exp $

</address>

Figura 18.7. Rappresentazione in un browser grafico del codice di marcatura nel Listato 18.3.

Inizio pagina

Metadati. L’elemento META

Un altro strumento per fornire informazioni semantiche per mezzo di metadati è l’elemento META, che può avere molteplici usi, anche non semantici, come il reindirizzamento ad altro documento. Un uso strettamente semantico è invece quello di provvedere descrizioni e parole chiave ad uso dei motori di ricerca. Un tale impiego di META ha a che fare con l’accessibilità in senso lato. Un documento ben indicizzato dai motori di ricerca, con le giuste parole chiave, sarà trovato più facilmente dagli utenti, rispetto a uno non indicizzato o reperibile solo attraverso parole chiave difficilmente collegabili al contenuto: sarà insomma più facile accedervi. Un documento web ben indicizzato è come un annuncio pubblicitario a nove colonne su un quotidiano, mentre un documento indicizzato male è come un piccolo annuncio in corpo 6, sperduto in una pagina secondaria del giornale.

Le Specifiche HTML 4.01 forniscono alcuni esempi sull’uso semantico di META. Uno dei più tipici è il seguente:

Listato 18.4. Uso di META in HTML con gli attributi keywords e description.

<META name="keywords" content="vacanze,Grecia,sole">

<META name="description" content="Vacanze idilliache in Europa">

L’attributo keywords va associato a una serie di parole chiave separate da virgole. L’attributo description va associato, invece, a una breve descrizione del contenuto della pagina o del sito.

È doveroso precisare che, nel corso degli anni, l’importanza che i motori di ricerca hanno attribuito ai contenuti di META ai fini dell’indicizzazione è andata via via diminuendo, a causa del cattivo uso che gli autori hanno fatto delle parole chiave. Tra i cattivi usi più comuni vi sono, per esempio, l’inserimento di una gran quantità di termini ripetuti, al fine di imbrogliare gli algoritmi di indicizzazione e ottenere così una classifica migliore nei risultati delle ricerche, oppure l’uso di termini che non hanno nulla a che fare col contenuto reale delle pagine, con lo scopo di dirottare sui propri siti utenti con tutt’altri interessi. Entrambe le pratiche, se scoperte, portano in genere alla cancellazione del sito responsabile dai database del motore di ricerca.

Inizio pagina

Metadati. RDF, ontologie e Web semantico

La sigla RDF sta per Resource Description Framework, che, tradotto in italiano, equivale a “Infrastruttura per la descrizione di risorse”. Si tratta di un gruppo di specifiche del W3C che formalizzano un linguaggio di marcatura basato su XML, il cui scopo è di fornire agli autori di contenuti un sistema altamente strutturato, in grado di descrivere semanticamente ogni tipo di contenuti per mezzo di metadati. RDF non è pensato per essere letto dagli umani, ma per consentire lo scambio di dati semantici tra le macchine, con l’idea di creare modi di organizzare e usare la conoscenza sempre più sofisticati e vicini ai bisogni degli esseri umani: ciò che comunemente viene indicato con il nome di “Web semantico”.

Riportiamo di seguito in traduzione italiana un brano dall’introduzione della Raccomandazione W3C RDF Primer collegamento esterno, che spiega i concetti essenziali su cui si fonda il linguaggio RDF.

Il Resource Description Framework (RDF) è un linguaggio per rappresentare informazioni sulle risorse nel World Wide Web. È progettato in particolare per rappresentare metadati relativi a risorse web, quali il titolo, l’autore e la data di modifica di una pagina web, informazioni sui diritti e le condizioni di licenza di un documento web o il piano di disponibilità di risorse condivise. Tuttavia, avendo generalizzato il concetto di “risorsa web”, RDF può essere usato anche per rappresentare informazioni su cose che possono essere identificate sul Web, ma non possono essere ricevute direttamente via Web (…).

RDF è pensato per situazioni in cui queste informazioni devono essere elaborate da applicazioni, piuttosto che soltanto visualizzate dalle persone. RDF fornisce un’infrastruttura comune per esprimere tali informazioni in modo che possano essere scambiate tra applicazioni senza perdite di significato. (…)

RDF è basato sull’idea di identificare le cose usando gli identificatori per il Web (chiamati Uniform Resource Identifiers, o URI) e descrivendo le risorse in termini di proprietà semplici e di valori di proprietà. Ciò permette a RDF di rappresentare dichiarazioni semplici sulle risorse come un grafico di nodi e archi, che descrive le risorse, le loro proprietà e i loro valori.

Figura 18.8. Il modello grafico che rappresenta una tripletta RDF (tratto da http://www.w3.org/TR/rdf-concepts/ collegamento esterno).

Ogni dichiarazione RDF ha la struttura di una tripletta di dati (RDF triple), costituita – in analogia con la struttura tipica di una frase nell’analisi logica – da un soggetto, un predicato e un oggetto. Il predicato, detto anche proprietà, indica il tipo di relazione che si stabilisce tra il soggetto e l’oggetto. Nella rappresentazione grafica di una tripletta RDF, soggetto e oggetto sono espressi come ellissi che rappresentano nodi, mentre il predicato è un arco (una linea), la cui direzione va dal soggetto all’oggetto.

Il Web semantico è una realtà complessa che, per essere attuata compiutamente, richiede una stratificazione di linguaggi, in grado di fornire strumenti di codifica con livelli di dettaglio sempre maggiore per i dati semantici. Una spiegazione di come è composto questo processo di stratificazione, che è tuttora in corso, è fornita nella sezione 1.2 della Raccomandazione W3C del 10 febbraio 2004 OWL Web Ontology Language Overview collegamento esterno:

Il Web semantico è una visione per il futuro del Web in cui alle informazioni viene dato un esplicito significato, in modo da rendere più facile per le macchine elaborare e integrare automaticamente le informazioni disponibili sul Web. Il Web semantico sarà costruito sulla capacità di XML di definire schemi di marcatura personalizzati e sull’approccio flessibile di RDF alla rappresentazione dei dati. Il primo livello sopra RDF richiesto per il Web semantico è un linguaggio per ontologie che possa descrivere formalmente il significato della terminologia usata nei documenti web. Se ci si aspetta che le macchine compiano compiti utili di ragionamento su questi documenti, il linguaggio deve andare oltre la semantica di base di RDF schema. (…)

OWL è stato progettato per venire incontro a questo bisogno di un linguaggio per ontologie del Web. OWL fa parte del gruppo in espansione di raccomandazioni W3C correlate al Web semantico.

OWL (che in inglese, considerato come parola e non come sigla, vuol dire “gufo”) è il linguaggio prodotto dal W3C per definire ontologie per il Web. Ma che cosa s’intende precisamente con questa strana e difficile parola – ontologia – presa dal gergo di logici e filosofi? Lo spiega un’altra Raccomandazione, OWL Web Ontology Language Use Cases and Requirements collegamento esterno (“Casi d’uso e requisiti del linguaggio per ontologie del Web OWL”):

Un’ontologia definisce i termini usati per descrivere e rappresentare un’area del sapere. Le ontologie sono usate da persone, basi di dati e applicazioni che necessitano di condividere informazioni su un dominio (un dominio è semplicemente una specifica materia o area del sapere, come la medicina, la fabbricazione di utensili, la vendita di immobili, la riparazione di automobili, la gestione finanziaria ecc.). Le ontologie includono definizioni, utilizzabili dai computer, di concetti di base all’interno del dominio e le loro relazioni (…) Esse codificano la conoscenza in un dominio e anche conoscenze che si estendono su più domini. In tal modo rendono la conoscenza riutilizzabile.

La parola ontologia è stata usata per descrivere manufatti con differenti gradi di struttura. Questi spaziano dalle semplici tassonomie (come la gerarchia di Yahoo) agli schemi per metadati (come il Dublin Core), alle teorie logiche. Il Web semantico ha bisogno di ontologie con un significativo grado di struttura, le quali devono essere in grado di specificare descrizioni per i seguenti tipi di concetti:

Listato 18.5. Come usare OWL per definire tre distinti colori per il vino.

<owl:AllDifferent>

<owl:distinctMembers rdf:parseType="Collection">

<vin:WineColor rdf:about="#Red" />

<vin:WineColor rdf:about="#White" />

<vin:WineColor rdf:about="#Rose" />

</owl:distinctMembers>

</owl:AllDifferent>

Inizio pagina

Ricerca per concetti e ricerca per stringhe di testo

Come si può intuire dai brani fin qui citati, il progetto del Web semantico, se è obiettivamente complesso, lo è perché si propone un obiettivo importante e ambizioso: quello di organizzare la sterminata mole d’informazioni disponibili sul Web in base alla semantica dei contenuti, cioè in base a ciò che essi significano per gli esseri umani. Ciò vuol dire acquisire la possibilità d’interrogare basi dati e motori di ricerca per concetti e non più per stringhe di testo.

È una differenza fondamentale. Gli strumenti informatici che rispondono oggi alle nostre interrogazioni sono per così dire stupidi: non distinguono il significato delle parole, ma badano unicamente a trovare nei documenti archiviati le corrispondenze, più o meno letterali, con la stringa di ricerca immessa dall’utente.

Per capire la differenza, facciamo un esempio concreto. Poniamo di voler interrogare Google per vedere se riusciamo a risalire alla declinazione (l’insieme delle forme grammaticali) della parola latina che significa “lepre”, della quale ricordiamo, dai tempi della scuola, solo una forma: il caso ablativo “lepore”. Interrogare Google usando la sola stringa “lepore” produce 2.100.000 risultati, una quantità incontrollabile da un umano. Nelle prime 20 pagine, prima che la stanchezza ci faccia desistere dal tentativo, troviamo solo una sfilza di rimandi a persone che di cognome fanno Lepore, un cognome comunissimo in Italia.

Possiamo restringere il campo di ricerca inserendo altre parole oltre “lepore”, per esempio “latino”, “declinazione”, “ablativo”. Ma alla fine il risultato di questa ricerca dipende in buona parte dalla casualità: cioè dalla possibilità che Google abbia indicizzato qualche documento che ha a che fare, magari alla lontana, con ciò che stiamo cercando, e, soprattutto, che ciò che cerchiamo capiti tra le prime pagine dei risultati. Riusciamo a trovare in effetti una pagina che parla dell’origine del cognome Lepore e che cita come possibile etimo “lepus, leporis”, che sono altre due forme (il nominativo e il genitivo) in cui si declina la parola latina che all’ablativo fa “lepore”; ma non troviamo nessuna pagina con la declinazione completa del sostantivo. Interrompiamo così la ricerca senza neppure sapere se una simile pagina web esista oppure no.

La ricerca sarebbe stata molto più breve e probabilmente fruttuosa, se avessimo potuto interrogare Google o un altro motore di ricerca per concetti; se avessimo potuto cioè dire al software, in un linguaggio comprensibile sia dall’uomo che dalla macchina, qualcosa come: “trova la declinazione completa della parola latina che all’ablativo singolare fa ‘lepore’”. Quando simili interrogazioni saranno possibili e porteranno ai risultati attesi, il Web semantico avrà raggiunto la sua piena attuazione, e l’insieme delle conoscenze disponibili in forma elettronica sarà di gran lunga più reperibile e accessibile di oggi.

Sarà forse un’epoca di computer intelligenti come Hal 9000 del film 2001: Odissea nello spazio.

Inizio pagina

Punto di controllo 13.3, priorità 2

Fornire informazioni sull’organizzazione generale di un sito (per esempio una mappa del sito o un sommario dei contenuti)

Si rivolge a: architetti dell’informazione, sviluppatori (tecnici del codice).

Mappare e descrivere i contenuti

Una ricerca svolta dalla società britannica User Vision su 208 utenti del Web, scelti tra persone la cui capacità di navigare era ostacolata da disabilità visive, uditive, motorie e dell’apprendimento, ha chiesto ai soggetti reclutati di elencare in termini d’importanza le caratteristiche di un sito che giudicavano più utili per facilitare la navigazione, come anche di elencare le caratteristiche giudicate più irritanti. I risultati di questa ricerca, riportati in un articolo disponibile sul sito della rivista Out-Law collegamento esterno, sono stati i seguenti.

La ricerca condotta da User Vision evidenzia la grande importanza che ha, per gli utenti con disabilità, la presenza di strumenti che consentono di semplificare la ricerca dei contenuti all’interno dei siti visitati. Subito dopo il motore di ricerca interno, l’ausilio più apprezzato è la mappa del sito (la presenza di testi alternativi per le immagini è risultata, invece, meno importante di quanto si credesse, non comparendo tra le cinque caratteristiche giudicate più utili). Chi sviluppa siti accessibili non dovrebbe, perciò, mai dimenticare di includere una mappa del sito, avendo cura di porre un collegamento ad essa, ben visibile, in tutte le altre pagine.

A proposito dell’importanza di fornire strumenti per aiutare l’utente a navigare con facilità tra i documenti di un sito, leggiamo cosa suggeriscono le Tecniche di base per le WCAG 1.0 (paragrafo 4 Navigation collegamento esterno).

Un meccanismo di navigazione crea un insieme di percorsi che un utente può seguire attraverso il vostro sito. Fornire barre di navigazione, mappe del sito e strumenti di ricerca: tutto ciò aumenterà la probabilità che gli utenti riescano a trovare ciò che stanno cercando nel vostro sito. Se esso ha una natura principalmente visuale, la sua struttura potrebbe essere più difficile da navigare, se l’utente non è in grado di formarsi una mappa mentale di dove sta andando e di dove è già stato. Per aiutarlo, gli sviluppatori di contenuti dovrebbero descrivere ogni meccanismo di navigazione. È d’importanza cruciale che le descrizioni e le guide del sito siano accessibili, dal momento che chi nel vostro sito si è perso, non può che fare affidamento su quelle.

Il testo del punto di controllo 13.2 è seguito da un suggerimento collegamento esterno che si ricollega al brano precedente: Nel descrivere il layout del sito, evidenziate e spiegate le caratteristiche di accessibilità disponibili.

Riassumendo: è importante realizzare mappe del sito, percorsi “a briciole di pane” (breadcrumbs, in inglese) e, dove necessari, sommari degli argomenti trattati, contenenti link diretti ai contenuti; è altrettanto importante che questi strumenti di orientamento e di navigazione siano accessibili. Occorre, infine, che le caratteristiche di accessibilità implementate siano evidenziate e descritte in qualche luogo del sito: la loro implicita presenza potrebbe non essere notata da alcuni tipi di utenti. A tal fine, è utile per esempio corredare un sito con una pagina dedicata all’accessibilità, in cui si descrivono le misure adottate, gli eventuali problemi non risolti e, se è il caso, le validazioni superate.

Figura 18.9. La precedente versione del sito del Governo italiano aveva una guida al sito molto completa, a cui rimandava una voce nella barra di navigazione orizzontale. La guida descriveva la struttura del sito e le misure di accessibilità implementate (5/4/2007). Purtroppo la versione corrente del sito del Governo non ha conservato questa utile pagina di orientamento.

Inizio pagina

Realizzare mappe testuali, evitare le mappe grafiche

Qualche anno fa era molto diffusa un’abitudine, oggi per fortuna quasi scomparsa: quella di realizzare mappe del sito e organigrammi in forma grafica.

Non era, e non è, una buona soluzione per l’accessibilità. In primo luogo, le mappe grafiche richiedono, come misura essenziale, di aggiungere testi alternativi che chiariscano la destinazione di ciascuno dei collegamenti in esse presenti. Quando i testi alternativi mancano, come accade, per esempio, nella complessa mappa in Figura 18.10, ne risulta per gli utenti di screen reader un’inaccessibilità più o meno totale, dove il “più o meno” dipende da quanto sono significativi i nomi dei file usati come valore di href (nel caso dell’organigramma in Figura 18.10 non lo sono per nulla: i file collegati hanno nomi come ssrd.htm, ases.htm, rium.htm, e così via).

Figura 18.10. Un organigramma realizzato in modalità grafica. Il suo codice di marcatura è completamente privo di testi alternativi e il documento è perciò inaccessibile per gli utenti di screen reader (5/4/2007).

In secondo luogo, anche aggiungendo tutti i necessari testi alternativi, non è possibile inserire all’interno di una mappa grafica quei titoli e quegli elenchi, che permetterebbero all’utente di screen reader di rappresentarsi la struttura dell’organizzazione o dei documenti elencati nella mappa.

In terzo luogo, i testi riprodotti in forma d’immagine sono poco leggibili per gli ipovedenti, a causa di problemi di ridimensionamento e di sfocatura.

Tutto ciò considerato, il modo migliore di realizzare una mappa del sito è per mezzo di link testuali, resi autoesplicativi ed opportunamente organizzati in forma gerarchica per mezzo di titoli ed elenchi (Figura 18.11).

Figura 18.11. La parte superiore della mappa del sito del Comune di Piegaro collegamento esterno, ben organizzata e accessibile (5/4/2007).

Inizio pagina

Punto di controllo 13.4, priorità 2

Usare i meccanismi di navigazione in maniera coerente.

Si rivolge a: grafici, sviluppatori (tecnici del codice).

Coerenza e incoerenza nei meccanismi di navigazione

Il punto di controllo 13.4 mette l’accento sull’importanza che i meccanismi di navigazione siano progettati in modo da avere un comportamento coerente. La coerenza, infatti, consente la predicibilità dei comportamenti e rende più semplice agli utenti acquisire familiarità con la navigazione in un sito.

È incoerente, per esempio, se i menu di navigazione cambiano di aspetto e di posizione da una pagina all’altra. È incoerente, ancora, se i collegamenti in un menu di navigazione a volte rimandano ad altri documenti, altre volte, invece, aprono dei sottomenu all’interno dello stesso menu, senza che ci sia un segnale che permetta di rendere predicibile la differenza di comportamento.

Altro fattore di incoerenza è far cambiare la forma del puntatore in una manina in corrispondenza di qualcosa che non è un collegamento ipertestuale o, al contrario, non far comparire la manina in corrispondenza di un collegamento ipertestuale. In entrambi i casi, si viola una delle convenzioni più conosciute e radicate nell’uso del Web: se la convenzione è rispettata, anche l’utente alle prime armi è in grado di riconoscere dalla forma del puntatore, indipendentemente dalle soluzioni grafiche scelte dagli autori, quali oggetti in un documento sono collegamenti ipertestuali e quali non lo sono.

Il sito web del Ministero della Salute collegamento esterno è un esempio di incoerenza nella disposizione e nell’aspetto di molti meccanismi di navigazione. A parte la testata, che mantiene correttamente aspetto e posizione costanti in tutte le pagine esaminate, tutti gli altri menu sono sottoposti al più alto tasso di variabilità. In home page (Figura 18.12 A) c’è un menu principale, posto sulla sinistra, che non compare in nessun’altra pagina esaminata, almeno non con lo stesso aspetto e con gli stessi link. Nella stessa pagina è presente, in basso a destra, un menu chiamato “Aree tematiche”, evidenziato nell’immagine con una bordatura. Questo menu compare solo in alcune pagine interne e, dove è presente, ha un aspetto completamente diverso, come mostra la Figura 18.12 B (la bordatura evidenzia la differenza). Le Figure 18.12 C e 18.12 D mostrano altre due pagine interne del sito del Ministero della Salute, che, messe a confronto tra loro e con le due precedenti, inducono a pensare che l’organizzazione dei meccanismi di navigazione in questo sito segue regole misteriose, o comunque troppo complesse per poterne ricavare una comprensione facile e immediata (l’esempio fatto per il sito del Ministero della Salute può essere esteso a molti altri siti della Pubblica Amministrazione italiana).







Figura 18.12. I meccanismi di navigazione nel sito del Ministero della Salute mostrano
un alto tasso di variabilità da pagina a pagina (5/4/2007).

Inizio pagina

Punto di controllo 13.5, priorità 3

Fornire barre di navigazione per evidenziare i meccanismi di navigazione e dare ad essi accesso.

Si rivolge a: grafici, sviluppatori (tecnici del codice).

Barre di navigazione

Il punto di controllo 13.5 è un invito a fornire agli utenti strumenti riconoscibili ed efficaci per consentire la navigazione in un sito. Una barra di navigazione, se ben realizzata, è appunto uno strumento di questo tipo: un oggetto distinto dal contenuto informativo di un documento, e tale da comunicare chiaramente all’utente la sua funzione.

Il 13.5 è un punto di controllo in un certo senso superato, non per quel che raccomanda, che è del tutto condivisibile, ma perché non c’è sito che nasca oggi sprovvisto di strumenti di navigazione. Abbiamo di solito, anzi, il problema opposto a quello paventato dal punto di controllo: una tale sovrabbondanza di menu, sottomenu, barre e controlli di modulo per la navigazione, da formare non di rado una matassa quasi inestricabile di contenuti accessori, che rischia di sommergere e oscurare i contenuti principali delle pagine.

Se la presenza di barre di navigazione è un dato pressoché standard in ogni sito, il modo di realizzarle e di posizionarle è, invece, tutt’altro che banale e scontato.

Il Web degli inizi, nei primi anni Novanta del secolo scorso, era una realtà per molti versi affine alla carta stampata: non essendovi ancora strumenti di espressione grafica e di personalizzazione delle interfacce, i contenuti, fatti soprattutto di testi e immagini, non erano molto diversi da quelli che avrebbero potuto finire in un libro o in una rivista scientifica.

A marcare in modo netto la differenza tra la carta stampata e il Web sono state, all’inizio, soprattutto le barre di navigazione e gli elenchi di link, cioè gli elementi che caratterizzano il Web come ipertesto, consentendo il passaggio immediato da un documento ad un altro; elementi che non esistono nel mondo della stampa, per il semplice fatto che l’unico mezzo per “saltare” da una pagina stampata a un’altra è girare i fogli con le mani (al massimo, indici e riferimenti bibliografici possono dirci dove andare a cercare altre informazioni).

Tale diversità ha richiesto l’invenzione di un’apposita grammatica espressiva, che, agli albori del Web, trovò nel colore blu sottolineato la forma di rappresentazione universale per marcare le stringhe di testo utilizzate come collegamenti ipertestuali. Non è mai emerso, al contrario, uno schema universale per rappresentare i menu di navigazione.

Figura18.13. Evoluzione del menu di navigazione principale del sito del Governo italiano tra il 1998 e il 2007: da sinistra, menu in uso il 2/12/1998, il 17/12/2000, il 5/2/2003, il 18/7/2007 (le prime tre immagini recuperate grazie alla “macchina del tempo” di Archive.org. Le dimensioni rispecchiano le effettive differenze di grandezza tra i menu).

Ciò che caratterizza ancor oggi una barra o un menu di navigazione è, infatti, semplicemente il fatto di essere un insieme riconoscibile di collegamenti, avente lo scopo di consentire all’utente di continuare l’esplorazione del Web a partire dal documento corrente. L’aspetto grafico, il numero e il tipo dei collegamenti, la posizione all’interno del documento sono soggetti alla più alta variabilità, anche se inevitabilmente si sono affermate nel tempo delle convenzioni, più o meno rispettate, ma comunque soggette anch’esse a cambiare, seguendo l’evoluzione delle tecnologie e degli stili di comunicazione.

[Inizio approfondimento] Accessibilità e convenzioni

Dal punto di vista dell’accessibilità, le convenzioni tacitamente riconosciute possono a volte costituire un problema. Le convenzioni, infatti, anche quando non rappresentano la miglior soluzione possibile, generano comunque aspettative negli utenti. Un caso tipico è il posizionamento dei menu di navigazione. Convenzionalmente, la maggior parte dei siti posiziona i menu, nel codice di marcatura, prima del contenuto principale di un documento. Per chi naviga con uno screen reader, sarebbe invece preferibile trovare i contenuti principali, almeno nelle pagine interne, prima dei menu, o almeno prima dei menu secondari. Spostare perciò la massa dei collegamenti a fondo pagina sarebbe in certi casi una soluzione di sviluppo sensata. Ma un tale cambiamento, andando contro una convenzione consolidata, può disorientare gli utenti di screen reader. Non trovando menu a inizio pagina, e dando per scontato che non possano essere altrove, potrebbero concludere che nel documento che stanno leggendo manchino del tutto i meccanismi di navigazione, soprattutto se, per la fretta, decidono di non esplorare il contenuto fino alla fine. Fortunatamente, l’uso di menu di scelte rapide e link di salto (si veda il commento al punto di controllo 13.6) può aiutare a conciliare, in questo caso, accessibilità e convenzioni. [Fine approfondimento]

[Inizio approfondimento] L’elemento NL di XHTML 2.0

Le future Specifiche XHTML 2.0 si prefiggono di porre rimedio al problema della mancanza, in HTML e in XHTML, di elementi strutturali per identificare i blocchi di navigazione della pagina. A tal fine, è stato predisposto un elemento NL, da usare come contenitore di barre e menu di navigazione. Tale elemento, la cui definizione si trova nel modulo per gli elenchi di XHTML 2.0 (XHTML List Module collegamento esterno, è progettato per essere usato in associazione con l’elemento LABEL, che servirà per identificare la funzione di ogni barra e menu di navigazione. Il Listato 18.6 adatta alla lingua italiana l’esempio presente nelle Specifiche XHTML 2.0. [Fine approfondimento]

Listato 18.6. Uso dell’elemento NL in XHTML 2.0.

<nl>

<label>Sommario</label>

<li href="#introduzione">Introduzione</li>

<li>

<nl>

<label>Definizioni</label>

<li href="#puo">Può</li>

<li href="#deve">Deve</li>

<li href="#dovrebbe">Dovrebbe</li>

</nl>

</li>

<li href="#conformità">Conformità</li>

<li href="#riferimenti">Riferimenti</li>

...

</nl>

Inizio pagina

Punto di controllo 13.6, priorità 3

Raggruppare i collegamenti correlati, identificare il gruppo (per i programmi utente), e, finché non lo faranno i programmi utente, fornire un modo per saltare il gruppo.

Si rivolge a: sviluppatori (tecnici del codice).

Meccanismi per saltare gruppi di contenuti ripetitivi

Le Tecniche HTML per le WCAG 1.0 spiegano le ragioni del punto di controllo 13.6 nel modo seguente (paragrafo 6.2 Grouping and bypassing links collegamento esterno):

Quando i collegamenti sono raggruppati in insiemi logici (per esempio in una barra di navigazione che appare in ogni pagina di un sito), dovrebbero essere marcati come un’unità. Le barre di navigazione sono di solito la prima cosa che si incontra in una pagina. Per gli utenti con sintetizzatori vocali, ciò vuol dire dover ascoltare una serie di collegamenti prima di raggiungere il contenuto interessante di una pagina. Vi sono numerosi modi per permettere agli utenti di saltare gruppi di collegamenti (come fanno i vedenti, quando riconoscono lo stesso insieme su ogni pagina):

Il testo citato prosegue fornendo un esempio di applicazione del punto di controllo 13.6 tramite uso congiunto di MAP e title, che riportiamo adattandolo all’italiano.

Listato 18.7. Codice HTML per un link di salto all’interno di un menu costruito con MAP.

<BODY>

<MAP title="Menu di navigazione">

<P>

[<A href="#come">Salta il menu</A>]

[<A href="index.html">Prima pagina</A>]

[<A href="cerca.html">Ricerca</A>]

[<A href="novita.html">Novità</A>]

[<A href="mappa.html">Mappa del sito</A>]

</P>

</MAP>

<H1><A name="come">Come utilizzare il nostro sito</A></H1>

<!-- segue il contenuto della pagina -->

</BODY>

Non ci risulta, però, che questa pratica di marcatura si sia diffusa tra gli sviluppatori.

Quel che invece è ormai utilizzato largamente sui siti progettati per l’accessibilità è il meccanismo dei link di salto. Anteporre ai blocchi ripetitivi di un documento, non solo ai menu di navigazione, un sistema per saltare al contenuto successivo è una pratica di sviluppo che si rivela essenziale per l’accessibilità. C’è accordo totale tra gli sviluppatori sulla necessità di implementare tale meccanismo. C’è invece meno accordo sul sistema migliore per implementarlo.

La questione al centro della discussione è come nascondere i link di salto agli utenti vedenti che navigano con i comuni browser grafici. Tali link, infatti, navigando in modalità grafica, possono risultare controproducenti per la comune usabilità di una pagina: se, infatti, un link di salto rimanda a un contenuto che, in una pagina multicolonna, si trova in una colonna diversa ma alla stessa altezza, l’utente che attiverà quel link in un browser grafico avrà l’impressione che non sia successo nulla, perché il contenuto visibile della pagina sarà rimasto immobile.

Vi sono, dunque, situazioni in cui gli sviluppatori preferiscono nascondere in modalità grafica i link di salto. Ma quale meccanismo adoperare a tal fine? Le soluzioni utilizzate nel corso degli anni dagli sviluppatori sono state numerose.

Uno dei primi metodi adoperati è stato quello di applicare il link di salto a un’immagine trasparente invisibile, nascondendo l’informazione testuale destinata agli utenti di screen reader nel valore dell’attributo alt dell’immagine, come nel seguente esempio.

Listato 18.8. Codice HTML per un’immagine invisibile che racchiude un link di salto.

<style type="text/css">

/* evita che compaia un bordo blu intorno all'immagine trasparente */

img {border:none}

</style>

......

<P>

<A href="#contenuto"><IMG src="trasparente.gif"

height="0" width="0" alt="[Salta il menu]"></A>

[<A href="home.html">Home</A>]

[<A href="search.html">Ricerca</A>]

......

</P>

Si noti che le dimensioni dell’immagine sono state impostate a 0 pixel, per impedire che possa comparire un’area attiva nel browser grafico, che induca l’utente, magari per sbaglio, a cliccarvi sopra. Inoltre, per far sì che non compaia sulla pagina alcun bordo intorno all’immagine invisibile, è stato utilizzato lo stile img {border:none}. La Figura 18.14 mostra la riproduzione in un browser testuale (A) e in un browser grafico (B) dello stesso menu di navigazione, contenente un link di salto codificato con la tecnica dell’immagine invisibile.

Il difetto del metodo dell’immagine invisibile è che, nella navigazione da tastiera in modalità grafica, riceverà il focus anche un collegamento – il link di salto, appunto – che non può essere visto dall’utente.



Figura 18.14. Un link di salto, inserito con la tecnica dell’immagine invisibile.

Con il progressivo miglioramento del supporto dei browser per i CSS, si diffuse il metodo di nascondere i link di salto usando l’istruzione {display:none}, che rendeva invisibili, nei browser conformi, i contenuti associati a questa istruzione, mentre JAWS, lo screen reader più utilizzato, riusciva invece a leggere e far usare all’utente i collegamenti nascosti. Tuttavia era il comportamento di JAWS ad essere anomalo, dal momento che non faceva ciò che l’istruzione CSS chiedeva, cioè di considerare come non esistenti sullo schermo i contenuti marcati con {display:none}. Gli altri screen reader nascondevano, invece, i link di salto, se collegati a quell’istruzione di stile. Uno studio in proposito è disponibile sulla rivista telematica A list apart, all’interno di un articolo di Joe Clark del 2003 intitolato Facts and Opinion About Fahrner Image Replacement collegamento esterno.

Gli sviluppatori di siti accessibili cominciarono perciò a utilizzare un diverso metodo per nascondere i link di salto per mezzo dei fogli di stile: il posizionamento assoluto in un’area esterna e lontana rispetto alla pagina visibile. Il Listato 18.9 modifica il codice del Listato 18.8, eliminando l’immagine invisibile e sostituendola con la tecnica cosiddetta off-left (“fuori a sinistra”).

Listato 18.9. Tecnica off-left (usa il posizionamento assoluto).

<style type="text/css">

.nascondi {

position:absolute;

top:-10000px;

left:-10000px;

}

</style>

......

<P>

<A href="#come" class="nascondi">[Salta il menu]</A>

[<A href="home.html">Home</A>]

[<A href="search.html">Ricerca</A>]

......

</P>

Una ricerca completa sull’argomento è stata realizzata da Bob Easton nel 2005 ed è consultabile sul blog Access Matters collegamento esterno. Mostra i risultati dei test effettuati provando ben dodici tecniche per nascondere i link di salto su numerosi screen reader e browser vocali.

Inizio pagina

Salta inserzione pubblicitaria

Menu di scelte rapide

La tecnica di nascondere dei contenuti con il posizionamento assoluto può essere adoperata per marcare non un solo link di salto, ma un intero menu di scelte rapide.

Nel caso si abbia un documento lungo e complesso, con più contenuti importanti che sarebbe utile rendere rapidamente disponibili agli utenti di screen reader, il menu di scelte rapide diventa una soluzione da prendere in seria considerazione. Poniamo il caso di avere una pagina, in cui il contenuto principale inizi dopo la testata e un paio di banner pubblicitari, ai quali seguano, dopo il contenuto principale, una casella di ricerca e il menu di navigazione. È possibile dare un accesso rapido ad uno qualsiasi dei tre blocchi significativi, ricorrendo a un piccolo menu come quello nel Listato 18.10, posizionato prima ancora della testata.

Listato 18.10. Codice HTML per un menu di scelte rapide.

<BODY>

<P class="nascondi">

<A href="#contenuto">Vai al testo</A>.

<A href="#ricerca">Ricerca nel sito</A>.

<A href="#menu">Menu di navigazione</A>.

</P>

<!-- Testata e banner pubblicitari -->

......

<H1><A name="contenuto"></A>Titolo del contenuto principale</H1>

......

<!-- Seguono funzioni di ricerca e menu di navigazione -->

Un menu di scelte rapide, inserito proprio all’inizio del documento, consente anche di non preoccuparsi troppo se sia meglio disporre nel codice prima i contenuti e poi i menu, o viceversa. Qualsiasi soluzione lo sviluppatore abbia scelto, l’utente con sintesi vocale avrà infatti la possibilità di raggiungere nel più breve tempo la parte del documento che gli interessa. È ovvio, però, che un menu di scelte rapide deve essere breve, anzi il più breve possibile: inserire più di due o tre collegamenti rischia di tramutarsi in un nuovo peso informativo da padroneggiare piuttosto che in un aiuto semplice e intuitivo per la navigazione.

Inizio pagina

I “paria” dell’accessibilità: gli utenti con disabilità motorie

Abbiamo discusso in queste ultime pagine dei metodi per nascondere i link di salto in modalità grafica, soprattutto quando possono confondere (o infastidire) gli utenti vedenti.

La scelta di nascondere questi strumenti di navigazione rischia però di penalizzare un’intera categoria di beneficiari dell’accessibilità. I link di salto, infatti, non servono solo agli utenti di screen reader, ma anche agli utenti con disabilità motorie, per consentir loro di raggiungere rapidamente le parti del contenuto di loro interesse. Per chi, infatti, non può usare il mouse o lo usa con grande difficoltà, il mezzo migliore per scorrere i contenuti è la navigazione da tastiera che, però, in pagine particolarmente complesse, rischia di tradursi in una lunga e penosa odissea. Disporre di link di salto visibili può essere dunque, per questo tipo di utenti, un grosso aiuto nella navigazione.

Ben pochi sviluppatori, purtroppo, sono consapevoli dei problemi di accesso ai contenuti dei disabili motori, che, dal canto loro, si sentono a ragione gravemente discriminati da soluzioni di accessibilità che non li aiutano, dal momento che sono mirate a risolvere soprattutto i problemi di navigazione di ciechi e ipovedenti.

Antonio Capoduro, informatico e disabile motorio che abbiamo già presentato ai lettori nel capitolo precedente, suggerisce un’interessante strategia di progettazione delle pagine web, allo scopo di renderle più accessibili ai disabili motori: suddividere le pagine indice in aree di contenuto (per esempio News, Interni, Esteri, Cronaca, Sport, nel caso di un quotidiano online), dando la possibilità all’utente di passare tabulando da una sezione all’altra in modo rapido. Solo dopo che si è scelta una sezione, si ha accesso da tastiera ai titoli in essa contenuti. L’idea è quella di ridurre al minimo le tabulazioni necessarie per arrivare a ciò che interessa; nell’attuale organizzazione dei siti informativi, invece, capita spesso di dover superare una lunga serie di collegamenti a contenuti accessori, prima di trovare il link alla sezione, all’articolo o all’informazione che si desidera leggere.

Per dare un’idea delle difficoltà, assolutamente ignote ai più, che incontra un disabile motorio nella normale navigazione sul Web, riportiamo ciò che ci ha scritto Antonio Capoduro in una comunicazione personale, raccontando la grande difficoltà di scrivere a un indirizzo e-mail che appare in una pagina web non in forma di collegamento ipertestuale, ma come testo semplice (una soluzione che molti autori adottano per ridurre il rischio di ricevere messaggi di posta indesiderati):

Ancorare un link a un indirizzo di posta elettronica, è vero, semplifica la vita ai professionisti dello spam, ma la semplifica anche a persone con difficoltà motoria. (...) molti siti, per evitare lo spam, non mettono il link all’indirizzo di posta elettronica. In questo caso, per poter scrivere una e-mail all’indirizzo in questione, è necessario compiere le seguenti operazioni in sequenza: 1) selezionare l’indirizzo con il mouse, 2) fare clic sulla parte selezionata con il tasto destro del mouse e 3) nel menu a comparsa scegliere Copia con il tasto sinistro del mouse; 4) fare clic su Start e 5) aprire il client di posta predefinito, 6) creare un nuovo messaggio, 7) posizionarsi con il mouse sul campo “A” (destinatario del messaggio), 8) fare clic con il tasto destro del mouse e 9) scegliere dal menu a comparsa la voce Incolla con il tasto sinistro. Ho voluto elencare la sequenza completa delle operazioni per rendervi consapevoli delle difficoltà enormi che un disabile motorio può incontrare. Tutto questo si ridurrebbe a un clic sul link della posta elettronica in questione. Semplificando la vita a molte persone, disabili e non. Essere consapevoli della scelta significa includere o escludere persone.

Inizio pagina

Delimitatori “pesanti” e delimitatori “leggeri”

Una delle funzioni principali dei meccanismi di salto è – lo abbiamo spiegato – rendere più rapido l’accesso alle informazioni agli utenti di screen reader. Va tenuto presente, però, che è possibile agevolare questa categoria di utenti anche in un altro modo, non meno importante: evitando, o riducendo al minimo, gli elementi che appesantiscono la lettura vocale degli screen reader.

Tra questi ultimi, sono da annoverare le parentesi quadre, che purtroppo sono usate spesso dagli autori di siti accessibili (e si trovano anche in alcuni esempi ricavati dalle WCAG, presenti in questo capitolo).

Per capire fino a che punto sia seccante l’ascolto ripetitivo di parentesi quadre che si aprono e si chiudono in continuazione, proviamo a far leggere a una sintesi vocale una serie di collegamenti consecutivi, come i tre nel Listato 18.9. Verrebbero letti, testualmente, così:

aperta parentesi quadralink di questa pagina: salta il menu – chiusa parentesi quadraaperta parentesi quadralink: home – chiusa parentesi quadraaperta parentesi quadralink: ricerca – chiusa parentesi quadra.

Il contenuto accessorio, cioè le parentesi quadre, finisce per occupare la gran parte del tempo di ascolto, molto più del breve contenuto informativo, costituito dal testo dei collegamenti e dall’avviso che si tratta di link.

È evidente, allora, il vantaggio che si ottiene, in termini di brevità di ascolto, usando un delimitatore meno “prolisso” delle parentesi quadre, come per esempio il punto o la virgola, che hanno il vantaggio di essere caratteri stampabili che, per impostazione predefinita, non vengono letti dalle sintesi vocali. Non casualmente, i tre collegamenti nel menu del Listato 18.10 sono separati l’uno dall’altro tramite punti. Ecco come JAWS 8.0 legge quella sequenza:

link di questa pagina: vai al testo – link di questa pagina: ricerca nel sito – link di questa pagina: menu di navigazione.

Rispetto all’esempio con le parentesi quadre, la seccante prolissità dei separatori è stata del tutto eliminata. Chi si occupa di accessibilità dovrebbe imparare a dare a queste apparenti sottigliezze l’importanza che meritano.

Inizio pagina

Punto di controllo 13.7, priorità 3

Se sono presenti funzioni di ricerca, rendere disponibili differenti tipi di ricerca per differenti livelli di abilità e differenti preferenze.

Si rivolge a: architetti dell’informazione, sviluppatori (programmatori, tecnici del codice).

Funzioni di ricerca scalabili

Le Tecniche di base per le WCAG 1.0 spiegano nel modo seguente le ragioni della raccomandazione contenuta nel punto di controllo 13.7 (sezione 4 Navigation collegamento esterno):

Gli utenti con disabilità della parola e quelli che non hanno familiarità con la lingua del vostro sito avranno difficoltà a trovare ciò di cui hanno bisogno, se la ricerca richiede una compitazione perfetta delle parole. I motori di ricerca dovrebbero includere un correttore ortografico, offrire alternative basate sul “miglior tentativo”, ricerche guidate per mezzo di esempi, ricerche basate sulla somiglianza ecc.

Ciò che chiede questo punto di controllo, benché sia del tutto condivisibile, è di difficile attuazione per chiunque non abbia i mezzi per sviluppare in proprio un motore di ricerca potente e sofisticato. Cercare di indovinare quello che l’utente voleva scrivere e, per errore di digitazione, non ha scritto; fornire alternative basate sulle parole somiglianti: sono funzioni che richiedono algoritmi complessi, tecniche di programmazione raffinate, che sono alla portata solo di pochi operatori specializzati.

È vero che il testo del punto di controllo 13.7 non specifica quali sono i livelli di scalabilità della ricerca che bisogna rendere disponibili all’utente, ma il brano del documento di tecniche citato poco sopra è ben chiaro in proposito, e rende di fatto piuttosto complicato applicare questo punto di controllo, rispettandone davvero il senso.

Persino un importante sito pubblico come quello del Ministero delle Finanze non possiede un sistema di ricerca interna in grado di suggerire correzioni e alternative. Se, per esempio, si digita “modello 770”, che è il nome corretto di un modulo per la dichiarazione dei redditi, il motore tira fuori oltre 200 risultati (Figura 18.15 A); ma basta commettere un errore di battitura molto comune, come quello di inserire una sola elle al posto delle due necessarie nella parola “modello”, per ottenere 0 risultati (Figura 18.15 B). Una persona con difficoltà nella lettura potrebbe non accorgersi di aver commesso un errore; potrebbe così essere indotta a ritenere che nel sito del Ministero non vi siano i documenti cercati, oppure che il motore di ricerca non funzioni a dovere.



Figura 18.15. Nel sito del Ministero delle Finanze, come in innumerevoli altri siti pubblici, non esiste un sistema per suggerire all’utente possibili correzioni per una stringa di ricerca anche solo leggermente sbagliata (23/4/2007).

[Inizio approfondimento] Operatori di ricerca

Il motore di ricerca del sito del Ministero delle Finanze contiene in verità degli elementi facilitatori della ricerca. È possibile usare per esempio il carattere asterisco (*), per sostituire qualsiasi stringa di caratteri: inserire nella casella di ricerca mod* indica, pertanto, al motore di trovare tutti i documenti che iniziano con “mod” (le istruzioni dettagliate sono alla pagina http://www.finanze.gov.it/motore_ricerca/help.htm collegamento esterno). Tuttavia questo e gli altri operatori resi disponibili dal motore di ricerca del sito del Ministero delle Finanze non sono paragonabili, quanto ad azione facilitatrice, all’automatica presentazione di alternative per la stringa immessa dall’utente. [Fine approfondimento]

Fortunatamente, chi desidera rispettare il punto di controllo 13.7 può fare a meno di tentare di realizzare in privato un piccolo Google, dotato di tutte le facilitazioni per l’utente richieste dal punto di controllo. Se, infatti, i documenti pubblicati su un sito sono indicizzati di frequente da almeno uno dei principali motori di ricerca, è possibile includere nell’interfaccia del sito la casella di ricerca di quel motore, delegando ad esso il compito di fornire strumenti di ricerca avanzati, tra i quali, in primo luogo, la funzione di suggerire alternative ragionate per gli eventuali errori di digitazione dell’utente (Figura 18.16).



Figura 18.16. Le pagine di Google e Yahoo!, che forniscono le istruzioni per inserire in altri siti le funzioni di ricerca dei due motori (23/4/2007).

Inizio pagina

Punto di controllo 13.8, priorità 3

Posizionare le informazioni distintive all’inizio di intestazioni, paragrafi, elenchi ecc.

Si rivolge a: autori, sviluppatori (tecnici del codice).

La lettura per “sfioramento”: cos’è e come favorirla

Il paragrafo 5.1 delle Tecniche di base per le WCAG 1.0 collegamento esterno è dedicato a consigli di stile per una scrittura accessibile. Contiene sette punti, il secondo dei quali spiega le ragioni che giustificano la raccomandazione nel punto di controllo 13.8:

Specificate all’inizio l’argomento della frase o del paragrafo (ciò che si chiama “pre-alimentazione” [front-loading]). Questo aiuterà sia le persone che “sfiorano” i testi visivamente sia quelle che usano sintetizzatori vocali. “Sfiorare” [skimming] con la sintesi vocale significa attualmente che l’utente salta da un’intestazione all’altra, o di paragrafo in paragrafo, ed ascolta il minimo indispensabile di parole per determinare se il blocco d’informazione corrente (titolo, paragrafo, link ecc.) gli interessa. Se l’idea principale del paragrafo è nel mezzo o alla fine, gli utenti vocali sono costretti ad ascoltare la maggior parte del documento prima di poter trovare ciò che desiderano.

La richiesta di questo punto di controllo è certamente giustificata dal punto di vista dell’accessibilità, ma riguarda un ambito che è spesso poco o nulla influenzabile dalle esigenze dello sviluppo accessibile: quello dei contenuti testuali.

Certo, se un testo deve essere composto specificamente per il Web, allora è auspicabile che sia scritto cercando di applicare con intelligenza ciò che raccomanda il punto di controllo 13.8. Tuttavia vi sono testi che nascono prima e indipendentemente dal Web e che nel Web trovano solo un luogo, o un ulteriore luogo, di diffusione: è il caso, per esempio, delle leggi e dei testi letterari. Non si può chiedere agli estensori di una legge o agli autori di un romanzo o di una poesia di tarare il proprio stile sulle esigenze della lettura per “sfioramento” degli utenti di sintetizzatori vocali.

Il 13.8 è dunque un punto di controllo che può essere applicato solo fino a un certo punto, cioè finché la natura dei testi da pubblicare sul Web lo consente. Inoltre appartiene a quel gruppo di punti di controllo per i quali è difficile, se non impossibile, valutare con criteri oggettivi se sia stato applicato oppure no: se abbiamo, ad esempio, un documento fatto di venti paragrafi, dei quali sedici hanno il contenuto distintivo più o meno all’inizio, due più o meno nel mezzo e due verso la fine, cosa diremo? Che il punto di controllo 13.8 è stato applicato oppure no? Non abbiamo una risposta per questa domanda.

Tutto ciò premesso, ci occorre ora un caso pratico, per mostrare come sia possibile applicare concretamente la raccomandazione di inserire i contenuti distintivi all’inizio dei vari blocchi che costituiscono un testo. A tal fine, ci è sembrato interessante proporre un esempio di riscrittura accessibile di una lettera, inviata nel 2001 dal Comune di Lucca ai cittadini. La lettera in questione non ha direttamente a che fare con il Web, ma è un esempio di comunicazione amministrativa e, come tale, si presta perfettamente ai nostri scopi.

Confrontando il testo originale della lettera con la successiva versione semplificata, apparirà evidente che lo spostamento dei contenuti salienti all’inizio non può avvenire, se non ripensando completamente il testo e riscrivendolo, con una struttura meglio organizzata e con uno stile più semplice e diretto.

In altre parole, il giusto suggerimento del punto di controllo 13.8 delle WCAG 1.0 va inserito all’interno di un più ampio e complesso discorso relativo allo stile generale della comunicazione scritta: se si riesce a rendere più semplice, chiaro e ordinato il linguaggio nel suo complesso, allora sarà anche più facile scrivere periodi in cui i concetti salienti siano immediatamente chiari anche a un lettore che ascolta poche parole per paragrafo e poi salta al successivo.

C’è chi pensa che l’accessibilità dipenda dalla qualità del codice di marcatura, ma il codice, per quanto possa essere scritto in modo professionale, non può sostituirsi alla scelta delle parole e all’uso della sintassi, che sono la base vera della comprensibilità di un testo. Il commento al punto di controllo 14.1 delle WCAG 1.0, nel Capitolo 19 di questo libro, tratterà ampiamente il tema della semplificazione dei testi per il Web: un compito che tocca agli autori di contenuti, non agli sviluppatori di codice.

Tuttavia, anche il codice di marcatura svolge un ruolo importante. Se, per esempio, un testo, invece di essere suddiviso in una serie di elementi P, è fatto da un unico P in cui gli a capo sono introdotti per mezzo di elementi BR, allora la lettura per “sfioramento” va a farsi benedire. Per uno screen reader, infatti, ci sarà un unico blocco nonostante gli a capo visibili in modalità grafica, sicché l’utente, premendo il tasto che serve per saltare di blocco in blocco, si ritroverà, senza saperlo, ad aver saltato tutto il testo in un solo colpo.

Pertanto, l’esempio che presentiamo di seguito, suddiviso in due listati, tiene conto di entrambi i fattori di accessibilità: del modo in cui il testo è scritto, che dipende dall’abilità degli autori, e del modo in cui è marcato, che dipende dalla competenza degli sviluppatori.

Il Listato 18.11. è l’esempio da non seguire. Riproduce una lettera realmente inviata dal Comune di Lucca ai cittadini nel novembre del 2001 (dalla quale abbiamo eliminato i periodi centrali, meno interessanti per i nostri fini). Non solo la lettera è scritta in un linguaggio involuto e burocratico, che non si presterebbe alla lettura per “sfioramento” nemmeno se il codice HTML fosse perfetto, ma l’abbiamo incorporata, per di più, in un HTML volutamente sbagliato, in cui i blocchi logici non appartengono a paragrafi differenti, ma a un unico elemento P.

Listato 18.11. Testo originale della lettera, con codice di marcatura poco accessibile.

<p>Gentile cittadino/a,<br>

allegato alla presente comunicazione trova un avviso
di liquidazione o accertamento ai fini ICI, derivante
dai controlli effettuati dall'ufficio, che ha anche
tenuto conto, ove possibile, delle osservazioni e
precisazioni eventualmente da Lei presentate a seguito
del ricevimento, nelle scorse settimane, degli appositi
preavvisi. Per tali ragioni l'avviso allegato dovrebbe
rispecchiare l'effettiva situazione esistente.<br>

Se tuttavia rilevasse degli errori può prendere contatto
con l'Ufficio Tributi, fissando un appuntamento per
telefono esclusivamente ad uno dei seguenti numeri
dell'URP (Ufficio Relazioni con il Pubblico), durante
l'orario di ufficio (lunedì, mercoledì e venerdì dalle
ore 9 alle ore 13; martedì e giovedì dalle ore 9 alle
ore 17): 0583 442429 , 0583 442041.<br>

(...)

In ogni caso si ricorda che la somma dovuta al Comune
dovrà essere pagata mediante il bollettino allegato
all'avviso, entro 90 giorni dal ricevimento.<br>

Nel pregarLa di volerci scusare per il disturbo che
Le arrechiamo, di cui tuttavia confidiamo comprenderà
le ragioni, ci è gradita l'occasione per porgerLe
distinti saluti.</p>

[Inizio approfondimento] Gli a capo marcati come elementi BR sono nemici della lettura per “sfioramento”

Inserire il testo in un unico elemento P non è un’astrazione teorica costruita a tavolino, ma la riproposizione di un caso comunissimo – e facilmente evitabile – di inaccessibilità. Chi crea HTML usando programmi visuali, e ignora allo stesso tempo gli strumenti usati dagli utenti di screen reader per leggere più rapidamente, non fa attenzione al modo in cui il programma visuale o il filtro di esportazione che sta adoperando trasformano i suoi a capo in codice HTML. È molto facile che ciò porti a una schiera di elementi BR, posti all’interno di un unico lungo elemento P. [Fine approfondimento]

Segue nel Listato 18.12. la riscrittura della stessa lettera in un linguaggio più accessibile, che diventa ancora più accessibile per un utente di screen reader, poiché il codice di marcatura è stato migliorato, usando tanti elementi P quanti sono i blocchi logici nel testo (corrispondenti a quelli che, in italiano, sono chiamati “capoversi”).

Entrambi gli scritti sono tratti da un documento in formato PDF, disponibile sul sito del Dipartimento della Funzione Pubblica nella sezione dedicata a Chiaro!, un progetto statale per la semplificazione del linguaggio amministrativo collegamento esterno. Il codice di marcatura è, in entrambi i listati, una nostra aggiunta.

Listato 18.12. Testo riscritto in forma più accessibile, con codice di marcatura accessibile.

<h1>OGGETTO: Pagamento dell'ICI dell'anno ....</h1>

<p>Gentile cittadino/a<br>
Le comunichiamo che per l'ICI dell'anno .... deve pagare l'importo di Euro ....... </p>

<p>Il pagamento deve avvenire comunque entro novanta giorni dalla data di ricevimento di questa comunicazione, mediante il bollettino che trova allegato.</p>

<p>Il termine va rispettato anche nel caso in cui lei ritenga che l'importo vada rivisto o intenda presentare un ricorso.</p>

<p>Allegato a questa lettera lei troverà l'"Avviso di liquidazione o accertamento" per verificare il modo in cui l'importo è stato calcolato.

<p><strong>Attenzione.</strong><br>
Il calcolo è stato eseguito in base ai controlli effettuati dal nostro ufficio e alle informazioni da lei eventualmente presentate dopo i nostri preavvisi. Per queste ragioni l'importo dovrebbe rispecchiare l'effettiva situazione esistente.</p>

<p>Se lei rilevasse ancora errori può fissare un appuntamento con l'Ufficio dei tributi.</p>

<p>A questo scopo dovrà telefonare ai numeri 0583 44 24 29 / 44 20 41 dell'Ufficio Relazioni con il Pubblico (URP), lunedì, mercoledì, venerdì dalle 9.00 alle 13.00; martedì e giovedì dalle 9.00 alle 17.00. (...)</p>

Leggendo il testo originale della lettera si resta perplessi: non si capisce bene il Comune cosa voglia. La lettera parte con un burocraticissimo riferimento a “un avviso di liquidazione o accertamento ai fini ICI” e solo alla fine avverte il cittadino che deve fare un versamento con il bollettino allegato, entro novanta giorni dal ricevimento.

La riscrittura semplificata risolve invece immediatamente l’ambiguità, grazie a un’essenziale scelta di chiarezza: l’uso della dicitura “OGGETTO”, seguita dalla breve spiegazione “Pagamento dell’ICI dell’anno …”. Allo sviluppatore non resta che marcare questa parte con un appropriato elemento d’intestazione (noi abbiamo usato H1). All’utente di screen reader basterà così un minimo sforzo di ascolto per capire l’argomento della lettera. E, dopo l’oggetto, si entra subito nel vivo: in modo molto stringato e preciso, il testo comunica al cittadino qual è l’importo di ICI da versare per l’anno segnalato e, a seguire, qual è il termine ultimo del pagamento. In sole quattro righe, la lettera ha fornito così tutte le informazioni essenziali. Non c’è più bisogno, nella versione riscritta, di ascoltare il testo integralmente solo per capire perché il Comune ha inviato quella comunicazione.

Si noti anche come quell’invito a fare attenzione, messo all’inizio del blocco che spiega come è stata determinata la cifra da versare, si presti perfettamente alla lettura per “sfioramento” e serva perciò realmente ad attirare l’attenzione dell’ascoltatore sugli importanti dettagli spiegati poco dopo: se “Attenzione” si trovasse dopo un BR, invece che all’inizio di un P, sarebbe invisibile in una lettura per “sfioramento”.

Del resto, tutto il testo della lettera nel Listato 18.12 può essere scorso rapidamente, saltando di blocco in blocco per mezzo della pressione ripetuta di un unico tasto (in JAWS, il tasto P), cosa che la lettera del Listato 18.11 non permette, chiusa com’è in un unico paragrafo.

Inizio pagina

Punto di controllo 13.9, priorità 3

Fornire informazioni sulle raccolte di documenti (cioè documenti che comprendono molteplici pagine).

Si rivolge a: sviluppatori (tecnici del codice).

Archivi compressi di documenti

Il punto di controllo 13.9 fa riferimento a due modi di fornire informazioni sulle raccolte di documenti. Il primo riguarda l’uso dell’elemento LINK, il secondo la creazione di archivi compressi di documenti, da mettere a disposizione degli utenti per lo scaricamento e la lettura in locale.

A proposito del secondo metodo, una nota acclusa al punto di controllo precisa:

Il miglioramento delle prestazioni, che si ottiene lavorando non connessi alla rete, può rendere la navigazione molto meno costosa per le persone con disabilità che navigano lentamente.

Mettere a disposizione gli archivi compressi dei file è in realtà, più che un modo di fornire informazioni sulla raccolta di documenti, un modo per distribuire agli utenti l’intera collezione dei documenti.

Molte Raccomandazioni del W3C sono un esempio di applicazione del punto di controllo 13.9. Nella loro testata sono infatti presenti i collegamenti per scaricare gli archivi compressi (solitamente nei formati ZIP e GZIP), che contengono i documenti che fanno parte della Raccomandazione. Le WCAG 1.0 appartengono ovviamente a questo gruppo.



Figura 18.17. La testata delle WCAG 1.0, con i link agli archivi compressi in evidenza (A). I file a cui si ha accesso dopo lo scompattamento dell’archivio ZIP scaricato in locale (B).

Inizio pagina

Barre di navigazione definite tramite l’elemento LINK

Il secondo modo di applicare il punto di controllo 13.9 riguarda l’uso dell’elemento LINK per descrivere la relazione tra il documento corrente e altri documenti appartenenti alla medesima collezione.

Perché usare LINK per un simile scopo? Perché i programmi utente conformi, trovando documenti che contengono relazioni ad altri documenti marcate con LINK, dovrebbero usare quelle relazioni per rendere disponibile agli utenti un menu di navigazione che le contenga. Si tratta, insomma, di un altro modo di realizzare un menu di navigazione: la differenza, rispetto alle normali barre progettate dagli sviluppatori e inserite nel corpo del documento, è che i menu creati con LINK appaiono nella posizione e con la forma previsti dal browser: prima del contenuto inserito in BODY o addirittura incorporati nell’interfaccia utente del browser invece che in quella del documento.

L’uso di LINK per definire relazioni con altri documenti è stato progettato con in mente essenzialmente un certo tipo di pubblicazioni testuali di carattere tecnico, quali sono, per esempio, proprio le Raccomandazioni del W3C. Lo dimostrano i tipi di relazioni definiti dalle Specifiche HTML 4.01: indici, sommari, appendici, glossari, capitoli, sezioni, sottosezioni, aiuti e notizie di copyright sono voci che si applicano perfettamente alla navigazione tra i documenti di una tipica Raccomandazione del W3C. Si tratta, tuttavia, di un’architettura che nasce espandibile (per mezzo della creazione di profili personalizzati di metadati) e che può essere facilmente adattata ad altri siti ed altre collezioni di documenti: i riferimenti a capitoli, sezioni e sottosezioni possono essere usati per ripartire qualsiasi tipo di contenuti, purché siano gerarchicamente organizzati.

Quello che segue è l’elenco dei valori di rel definiti nelle Specifiche HTML 4.01 (sezione 6.12 Link types).

Il Listato 18.3 mostra un esempio, ricavato dalla traduzione italiana delle Specifiche CSS2 (capitolo 11 Effetti visivi collegamento esterno), in cui l’elemento LINK è usato proprio per fornire informazioni sulla collezione di documenti (sono stati aggiunti alcuni elementi LINK in più, rispetto a quelli originariamente presenti nel codice di marcatura del documento).

Listato 18.13. Uso di LINK e rel per creare un menu di navigazione.

<head>

......

<title>Effetti visivi</title>

<link rel="stylesheet" href="style/default.css" type="text/css">

<link rel="start" href="cover.html" title="Copertina">

<link rel="prev" href="visudet.html"

title="Il modello di formattazione visuale">

<link rel="next" href="generate.html" title="Contenuti generati">

<link rel="contents" href="cover.html#minitoc" title="Sommario">

<link rel="appendix" href="propidx.html"

title="Appendice F. Indice delle proprieta'">

<link rel="index" href="indexlist.html" title="Indice analitico">

<link rel="copyright" href="about.html#copyright"

title="Note sul diritto d'autore">

......

</head>

Le voci che indicano le relazioni con altri documenti (start, prev, next ecc.) vanno inserite nel codice come valori dell’attributo rel. L’attributo title è usato, invece, per fornire una descrizione del documento collegato, ad uso dell’utente umano.

[Inizio approfondimento] Altri usi dell’attributo rel

L’attributo rel è usato anche per altri tipi di relazioni: per esempio, per referenziare un foglio di stile (valore stylesheet) o una versione alternativa di un documento (valore alternate). [Fine approfondimento]

Non tutti i browser, purtroppo, sono in grado di riprodurre i menu di navigazione creati con LINK. Tra quelli che hanno supporto per questa funzione, vi sono il browser testuale Lynx e i browser grafici Opera, iCab e SeaMonkey (Figura 18.18).

I quattro browser usano altrettante diverse (ma simili) strategie di riproduzione.

Lynx (Figura 18.18 A) riproduce il menu di navigazione usando come voci le didascalie inserite nell’attributo title degli elementi LINK. Il menu appare nel corpo del documento, come suo primo contenuto.

Opera (Figura 18.18 B) usa invece come voci del menu i valori dell’attributo rel, tradotti in italiano nella versione localizzata del browser; dà, cioè, la priorità al tipo di relazione che la voce di menu ha con il documento corrente: indice, contenuti, successivo, precedente ecc. Si noti che alcune voci sono in grassetto, a indicare che sono attive, altre in grigio chiaro, a indicare che sono disabilitate: quelle in grassetto corrispondono agli elementi LINK definiti nel codice di marcatura, quelle in grigio chiaro sono definite dalle Specifiche ma non utilizzate nel documento. Da notare la possibilità di attivare il collegamento al documento successivo nella collezione, se presente, per mezzo di una scorciatoia da tastiera standardizzata (Ctrl + Shift + freccia a destra). Il menu è incorporato nell’interfaccia utente del browser.

Anche il menu generato da iCab 3.0.3 (Figura 18.18 C) è incorporato nell’interfaccia del browser, ma, a differenza del menu di Opera, contiene icone rappresentative della funzione al posto delle etichette testuali: il simbolo della casetta equivale al valore start di rel, le frecce che puntano a sinistra e a destra equivalgono rispettivamente ai valori prev e next, e così via. La barra di iCab contiene inoltre una soluzione interessante: l’ultima icona è un triangolino orientato verso il basso, facendo clic sul quale compare un menu a discesa, le cui voci sono costituite dai valori degli attributi title inseriti negli elementi LINK.

Nella barra generata da SeaMonkey, evoluzione del browser Open Source Mozilla (Figura 18.18 D), i menu a discesa sono addirittura due, apribili tramite le cartelle Document e More. Le possibilità di navigazione offerte sono le più complete. Il titolo del documento collegato, cioè il valore di title dell’elemento LINK, appare al passaggio del mouse sulle voci attive della barra.







Figura 18.18. Nel riquadro in evidenza, un menu di navigazione realizzato con LINK, riprodotto in quattro diversi browser: Lynx 2.8.6 (A), Opera 9.10 (B), iCab 3.0.3 (C), SeaMonkey 1.1.1 (D).

Inizio pagina

L’elemento LINK e il problema del supporto mancante

Osservando i quattro esempi in Figura 18.18, è facile rendersi conto che le voci presenti nelle barre generate tramite LINK duplicano le voci nel menu di navigazione incorporato nel documento (“precedente”, “successivo”, “sommario”, “proprietà”, “indice”). Non è una cosa buona per l’utente trovare due volte gli stessi collegamenti nel medesimo documento, a poca distanza gli uni dagli altri: nel migliore dei casi sarà percepito come una perdita di tempo, nel peggiore sarà un fattore di confusione. Se si usa LINK per creare un menu di navigazione, si dovrebbe usare LINK e basta, senza inserire nel corpo del documento un altro menu uguale, realizzato con elementi A.

Il problema è che i menu generati con LINK non hanno un adeguato supporto da parte dei principali programmi utente, ragion per cui non si può evitare di crearne un doppione, fatto con elementi A posti nel corpo del documento. In caso contrario, la maggior parte degli utenti non avrebbe a disposizione alcuno strumento per navigare tra i documenti della raccolta.

Internet Explorer, per esempio, anche nell’ultima versione, la 7.0, ignora completamente le relazioni ad altri documenti definite con i valori di rel elencati in precedenza. Trattandosi del browser di gran lunga più usato (anche in accoppiata con le tecnologie assistive), il suo comportamento è valso come una bocciatura senza appello della possibilità di creare menu per mezzo dell’elemento LINK. Una possibilità su cui ha posto una pietra tombale Firefox, il secondo browser più usato al mondo, che, per quanto faccia almeno lo sforzo di mostrare i collegamenti definiti per mezzo di LINK in una finestra d’informazioni sul documento caricato, non offre però alcun meccanismo di navigazione verso i documenti correlati (Figura 18.19).

Figura 18.19. I collegamenti definiti tramite LINK sono mostrati da Firefox 2.0 in una finestra di informazioni sul documento, che non offre però meccanismi diretti di navigazione.

Visto che il comportamento dei principali browser rende inutile, al momento, usare l’elemento LINK per l’applicazione del punto di controllo 13.9, è lecito chiedersi perché mai ci siamo dilungati tanto nella trattazione di questo argomento. La ragione è duplice: da un lato fornire al lettore elementi informativi poco noti, dall’altro stimolare, se fosse ancora possibile, l’uso di LINK per i menu di navigazione. In fondo, come dimostrano le implementazioni fornite da Lynx, Opera, iCab e SeaMonkey, il problema del supporto è risolubile. Se gli sviluppatori di contenuti per il Web cominciassero a produrre documenti che abitualmente comprendono serie di collegamenti definiti con LINK, è probabile che i produttori di browser adeguerebbero rapidamente i loro prodotti alla nuova esigenza.

È un vero peccato, infatti, che i programmi utente più diffusi abbiano deciso di non supportare l’utilizzo di LINK, suggerito dal punto di controllo 13.9 delle WCAG 1.0. Assegnare ai browser il compito di generare barre per navigare tra documenti semanticamente collegati sarebbe un ottimo ausilio per l’accessibilità. In una situazione di documenti e browser forniti di supporto per l’uso di menu creati con LINK, gli utenti troverebbero con facilità i collegamenti per continuare la navigazione, perché li cercherebbero su un menu standardizzato per posizione, aspetto e tipo di contenuti: qualcosa di molto diverso dall’estrema variabilità che caratterizza l’implementazione attuale dei menu di navigazione posti nel corpo del documento, i quali differiscono da sito a sito e spesso da una sezione all’altra dello stesso sito (si veda in proposito l’esempio del Ministero della Salute, nel commento al punto di controllo 13.4).

Per di più, i menu realizzati nel corpo del documento per mezzo di elementi A usano non di rado tecniche inaccessibili, quali etichette grafiche, caratteri troppo piccoli, oggetti lampeggianti ecc.: problemi di accessibilità che l’uso di LINK eliminerebbe di colpo. Sarebbe ridotta anche la necessità di ricorrere ai link di salto, per evitare i blocchi di contenuti ripetitivi, quali sono appunto menu e barre di navigazione.

Come ulteriore beneficio, l’implementazione da parte dei browser di meccanismi di navigazione definiti tramite LINK permetterebbe di standardizzare anche l’uso, oggi problematico, degli accesskey (si veda in proposito il commento al punto di controllo 9.5, nel Capitolo 14). Toccherebbe, infatti, ai browser definire la scorciatoia da tastiera per ogni tipo di relazione, come già fa Opera, per esempio, con la combinazione Ctrl + Shift + freccia a destra, scelta per aprire il documento che è referenziato dall’attributo rel="next" di LINK.

Gli sviluppatori, dal canto loro, finalmente liberi dall’obbligo di progettare menu di navigazione grafici e di definire eventuali accesskey, potrebbero concentrarsi soprattutto sui contenuti, riducendo di molto il numero dei collegamenti inseriti mediamente in un singolo documento. Si tratterebbe di ritornare in un certo senso all’origine del Web, almeno per i siti interessati all’accessibilità e basati sulla prevalenza del contenuto sul contenitore (dove per “contenitore” intendiamo l’interfaccia utente del documento caricato nel browser, con i suoi strumenti di orientamento e di navigazione).

Quando gli elementi di navigazione sono troppo numerosi e variabili per aspetto e per posizione, l’attenzione del lettore non sa dove poggiare: tutto reclama attenzione e nulla sembra meritarla. Se poi vi sono, come spesso capita, anche banner pubblicitari a profusione, allora il “rumore di fondo”, cioè il sovraccarico informativo, rischia di diventare assordante: scorrere, leggere e comprendere i contenuti principali può diventare difficoltoso come cercare di fare conversazione durante un concerto di musica heavy metal.

A ben riflettere, i documenti stampati su carta non soffrono di questo problema: in un libro o in una rivista, è tutto contenuto informativo; il lettore non deve perdere tempo a cercare strumenti di orientamento; la “navigazione” si riduce ai sommari e agli indici posti all’inizio e alla fine dei testi, e ai rimandi alle eventuali note a pie’ di pagina. Certo, il Web è una realtà diversa, ma se si potesse recuperare un po’ dell’originaria semplicità delle interfacce utente, senza per questo rinunciare alla raffinatezza delle soluzioni grafiche più recenti, sarebbe un gran bene per l’accessibilità dei contenuti. E la possibilità di standardizzare l’aspetto, la struttura e la posizione dei menu di navigazione, trasferendo il compito ai browser per mezzo di un recuperato supporto per l’elemento LINK, sarebbe un grande passo in avanti nella giusta direzione.

Inizio pagina

Salta inserzione pubblicitaria

Punto di controllo 13.10, priorità 3

Fornire un modo per saltare l’arte ASCII che si sviluppa su più righe.

Si rivolge a: sviluppatori (tecnici del codice, programmatori).

Arte ASCII e sintetizzatori vocali

Per arte ASCII si intende una serie di caratteri (lettere, numeri, simboli di punteggiatura), disposti su una o più righe a costituire delle figure stilizzate, come nel Listato 18.14, che, usando punti, virgole, trattini, parentesi, apostrofi ecc., riproduce l’immagine di un branco di pesci che nuota da sinistra verso destra.

Il punto di controllo 13.10 raccomanda agli sviluppatori di fornire un metodo per consentire agli utenti di saltare l’arte ASCII che si sviluppa su più righe. La ragione del suggerimento è facilmente intuibile: i caratteri di cui sono composte simili figure sono letti da un sintetizzatore vocale come fossero testo normale, con un risultato che è totalmente incomprensibile, oltre che terribilmente noioso da ascoltare.

Listato 18.14. Un esempio di arte ASCII.

.·´¯`·.¸¸.·´¯`·.¸¸. ><((((º>

.·´¯`·.¸¸.·´¯`·.¸¸. ><((((º>

¯`·.¸¸.><((((º>

><((((º> .·´¯`·.¸¸.·´¯`·.¸¸. ><((((º>

¯`·.¸¸.><((((º>

¯`·.¸¸.><((((º>¯`·.¸¸. ><((((º>

.·´¯`·..¸¸.·´¯`·.¸¸. ><((((º>

Le Tecniche HTML per le WCAG 2.0, un documento tuttora in fase di elaborazione, contengono un esempio di codice che dà all’utente la possibilità di saltare un blocco di arte ASCII collegamento esterno. Presentiamo qui l’esempio, dopo averlo adattato all’italiano:

Listato 18.15. Codice XHTML per saltare un blocco di arte ASCII.

<a href="#post-arte">Salta l'arte ASCII</a>

<!-- Qui va il disegno realizzato con l'arte ASCII -->

<a id="post-arte" name="post-arte">Una raffigurazione di pesci

in movimento realizzata con l'arte ASCII</a>

Sia il link di salto che la didascalia possono eventualmente essere resi invisibili, usando la tecnica CSS off-left, illustrata nel commento al punto di controllo 13.6.

Inizio pagina

Tecniche di accessibilità per la micro-arte ASCII

Al di là dell’arte ASCII che si sviluppa su più righe, oggi piuttosto rara, alla quale fa riferimento il punto di controllo 13.10, esiste quella che potremmo definire una micro-arte ASCII, fatta di pochi caratteri consecutivi e usata sul Web molto più di frequente. Ci riferiamo all’abitudine di utilizzare caratteri di testo come separatori e come “indicatori di direzione” dei collegamenti.

L’uso riguarda, per esempio, le cosiddette “briciole di pane” (breadcrumbs) e i collegamenti di navigazione, come quelli che invitano a continuare la lettura di un articolo o che rimandano al documento precedente o successivo in una collezione di documenti. I caratteri più utilizzati a questo scopo sono le parentesi angolari destra (">") e sinistra ("<"), che vengono lette, dai sintetizzatori vocali impostati per l’italiano, rispettivamente come “maggiore di” e “minore di”. Quando i due segni sono usati senza nessuna implicazione matematica, l’effetto sulla comprensione può essere negativo, oltre che sicuramente noioso. Il problema è che, mentre i caratteri "<" e ">", con la loro forma a punta, servono egregiamente a indicare una direzione all’utente che può vedere, tradotti nel loro equivalente testuale (“minore di” e “maggiore di”), spesso perdono di utilità.

Per capire di cosa stiamo parlando, consideriamo il percorso a briciole di pane mostrato in Figura 18.20, presente in una pagina interna del sito della Polizia Penitenziaria collegamento esterno.

Figura 18.20. Uso del carattere “>” come separatore in un percorso a briciole di pane.

Sottoponendo la stringa a JAWS 8.0, otteniamo la seguente lettura:

Maggiore di link struttura maggiore di link indirizzi maggiore di provveditorato Catanzaro.

Non ci sembra il massimo dell’accessibilità, anche perché non c’è nulla che aiuti l’ascoltatore a capire che ciò che sta ascoltando è il percorso a briciole di pane della pagina corrente.

Non è difficile migliorare l’accessibilità del blocco. Innanzitutto, si può segnalare all’utente che si tratta di un percorso. Molti siti lo fanno, premettendo alla stringa la segnalazione “Ti trovi in”, o qualcosa di simile, come fa, per esempio, Pubbliaccesso.gov (Figura 18.21).

Figura 18.21. Uso di una premessa per contestualizzare un percorso a briciole di pane (da http://www.pubbliaccesso.gov.it collegamento esterno).

Ecco come JAWS 8.0 legge un simile percorso:

Ti trovi in due punti link home page trattino link biblioteca trattino link manualistica trattino link manuale destinazione web.

A nostro parere, se si eliminasse il separatore tra i link, qualsiasi esso sia, la qualità dell’ascolto ne guadagnerebbe. Basterebbe la breve premessa “ti trovi in”, per far capire all’utente di screen reader che sta ascoltando un percorso a briciole di pane.

Naturalmente i separatori hanno anche una funzione visiva, per cui andrebbero eliminati solo dalla sequenza di ascolto. Un metodo per non far leggere a una sintesi vocale uno o più caratteri separatori è quello di usare al loro posto un’immagine che li rappresenta, associata a un testo alternativo vuoto (alt="").

[Inizio approfondimento] Secondo alcuni il separatore migliore per le briciole di pane è “>”

Sosteniamo qui la teoria che “maggiore di” sia un separatore troppo prolisso anche per un percorso a briciole di pane e, soprattutto, che abbia un significato non perfettamente chiaro, almeno per quegli utenti che non hanno dimestichezza con questa convenzione. Altri la pensano diversamente. In un articolo sul sito del Royal National Institute of the Blind collegamento esterno (“Reale Istituto dei Ciechi”), la tesi sostenuta è che ascoltare “maggiore di”, tra due link collegati in un percorso a briciole di pane, dia all’ascoltatore un’importante informazione strutturale, che merita di essere conservata. [Fine approfondimento]

Il problema di rendere accessibile la micro-arte ASCII non riguarda, naturalmente, solo i percorsi a briciole di pane. Consideriamo, per esempio, la tabella calendario in Figura 18.22, tratta dal sito del Ministero dello Sviluppo Economico collegamento esterno.

Figura 18.22. Una tabella-calendario, in cui i caratteri “<<” e “>>” sono usati per indicare il passaggio al mese precedente e al mese successivo.

All’ascolto con JAWS, la prima riga della tabella dà questo risultato:

link minore di minore di aprile 2007 link maggiore di maggiore di.

È vero che, con l’abitudine, si può riuscire a capire il senso anche di una simile filastrocca, ma uno sviluppatore che abbia un minimo di competenza nel campo dell’accessibilità non deve faticare poi molto per rendere le cose più semplici a un utente di screen reader. Una soluzione facile, per esempio, è sostituire le sequenze di caratteri “<<” e “>>” con immagini di aspetto equivalente, associate, rispettivamente, ai testi alternativi alt="mese precedente" e alt="mese successivo".

Un altro metodo per ottenere lo stesso risultato, ma senza l’uso di immagini, consiste nel ricorrere all’elemento ABBR: si marca con ABBR il gruppo di caratteri che non deve essere letto dalla sintesi vocale, e si inserisce nel valore dell’attributo title di ABBR il testo sostitutivo che la sintesi deve leggere al posto di quello.

Il Listato 18.16 mostra come usare ABBR per evitare la lettura dei caratteri “<<” e “>>” nella tabella-calendario di Figura 18.22.

Listato 18.16. Uso di ABBR per sostituire la micro-arte ASCII con testi significativi.

<tr>

<td>

<a href="..."><abbr title="mese precedente">&lt;&lt;</abbr></a>

</td>

<td colspan="5">Aprile 2007</td>

<td>

<a href="..."><abbr title="mese successivo">&gt;&gt;</abbr></a>

</td>

</tr>

Inizio pagina

“Faccine” accessibili

L’elemento ABBR può essere usato per rendere accessibile anche un altro tipo di arte ASCII di uso comunissimo: le cosiddette “faccine”, o emoticons, cioè quelle sequenze di caratteri che, soprattutto all’interno di forum, chat, blog e messaggi di posta elettronica, sono usate per rappresentare schematicamente le emozioni che chi scrive vuole comunicare a chi legge. Può sembrare un argomento di importanza secondaria, ma la funzione comunicativa delle faccine è incontestabile e il loro uso sul Web larghissimo: non è corretto, pertanto, soprattutto in certi contesti, ignorare la loro ricaduta sull’accessibilità. Consideriamo le frasi seguenti, copiate a caso da un interminabile scambio di commenti, all’interno di un blog come ce ne sono tanti:

A. Adesso so chi sei ;-) Grazie per la telefonata ^___^

B. Ciao :-) Un bacione. Buona serata

A. Vai già via? Peccato! Ciao... :(

Come legge JAWS questo breve scambio di battute? Così:

A. Adesso so chi sei punto e virgola trattino chiusa parentesi tonda Grazie per la telefonata accento circonflesso sottolineato sottolineato sottolineato accento circonflesso

B. Ciao due punti trattino chiusa parentesi tonda Un bacione Buona serata

A. Vai già via? Peccato! Ciao punto punto punto due punti aperta parentesi tonda

Per quanto l’esperienza aiuti l’utente di screen reader a decifrare il senso di quest’uso particolare della punteggiatura, sarebbe comunque preferibile, dal punto di vista dell’accessibilità, che la sintesi vocale potesse leggere – al posto, per esempio, di “accento circonflesso sottolineato sottolineato sottolineato accento circonflesso” – un equivalente sintetico e significativo. Per tale scopo, l’elemento ABBR può fare al caso nostro, e il Listato 18.17 ci mostra in che modo.

Listato 18.17. Uso di ABBR per fornire un equivalente significativo alle “faccine”.

<p>Adesso so chi sei <abbr title="[occhietto]">;-)</abbr>

Grazie per la telefonata

<abbr title="[sorriso radioso]">^___^</abbr></p>

<p>Ciao <abbr title="[sorriso]">:-)</abbr> Un bacione. Buona serata</p>

<p>Vai già via? Peccato! Ciao...

<abbr title="[faccina triste]">:(</abbr></p>

È ovvio che non si può pretendere che i frequentatori di forum, blog e chat, dopo aver scritto una faccina, si ricordino di marcarla con l’elemento ABBR, o in qualche altro modo, e di fornire un appropriato equivalente testuale, così da renderla accessibile agli utenti di screen reader. Non solo sarebbe un’operazione terribilmente lenta e noiosa, ma occorrerebbe prima spiegare cosa sono ABBR e l’accessibilità a utenti che, in larga maggioranza, ignorano il linguaggio HTML e le tematiche trattate in questo libro.

La soluzione è a monte, cioè lato server. Forum, blog e chat accessibili dovrebbero prevedere in partenza meccanismi di conversione automatica, in virtù dei quali determinate sequenze di caratteri immesse dagli autori, tra cui quelle del Listato 18.17, appaiano nella pagina pubblicata associate a un equivalente testuale significativo.

[Inizio approfondimento] Quando le parentesi servono

Il lettore attento avrà notato una contraddizione tra l’invito a non usare le parentesi quadre come delimitatori, contenuto in un paragrafo precedente di questo capitolo (Delimitatori “pesanti” e delimitatori “leggeri”), e l’esempio del Listato 18.17, in cui gli stati d’animo rappresentati dalle faccine sono racchiusi proprio tra parentesi quadre. In realtà non c’è contraddizione, perché i due usi sono differenti. Un menu di scelte rapide fa parte del normale flusso dei contenuti, e dunque non è necessario appesantirne la lettura con le parentesi, che indicano separazione tra ciò che è dentro e ciò che è fuori. Le faccine sono, invece, metacontenuto, cioè un qualcosa che sta a un altro livello rispetto al testo dei commenti: è necessario, perciò, che siano messe tra parentesi. Se così non fosse, il testo ascoltato sarebbe ambiguo (“Adesso so chi sei occhietto” è diverso da “Adesso so chi sei aperta parentesi quadra occhietto chiusa parentesi quadra”). [Fine approfondimento]

Del resto, molti siti web di socializzazione utilizzano da tempo meccanismi di conversione automatica, che trasformano le sequenze di caratteri identificate come faccine in immagini che le rappresentano. Il noto forum di HTML.it, per esempio, dispone di un’ampia “grammatica” di faccine, descritta in una tabella che mostra la corrispondenza tra la sequenza da digitare, il significato della faccina e l’immagine che apparirà nella pagina pubblicata collegamento esterno. La Figura 18.23 riporta l’inizio della tabella.

Purtroppo l’implementazione attuale del meccanismo non dà risultati accessibili, come mostra il Listato 18.18, che riporta un breve estratto dal codice di marcatura di un messaggio nel forum di HTML.it. La mancanza di valori per gli attributi alt rende infatti le faccine mute, anzi inesistenti, per gli utenti di screen reader.

Listato 18.18. Implementazione inaccessibile della conversione delle “faccine” in immagini.

<div class="corpopost">

Assolutamente si! <img src="images/smilies/tupitupi.gif"

alt="" border="0"><br>

Lo cercavo da non so più quanto tempo!<br>

Grazie!!! <img src="images/smilies/biggrin.gif"

alt="" border="0"><br>

<br>

P.S. Ho appena ridato un'occhiata: è splendido! <img src="images/smilies/zizi.gif" alt="" border="0"></div>

Al codice di marcatura del Listato 18.18 corrisponde la visualizzazione nella pagina del forum mostrata in Figura 18.24.

Figura 18.24. Riproduzione in un browser grafico del codice nel Listato 18.18.

Per comunicare gli stati d’animo espressi dalle faccine anche a un utente di screen reader, basterebbe migliorare il meccanismo già esistente di conversione automatica delle sequenze immesse dagli autori, aggiungendo a ogni immagine un valore di alt corrispondente al significato della relativa faccina. Il Listato 18.19 mostra un esempio con dei possibili testi alternativi per le tre faccine di Figura 18.24.

Listato 18.19. Immagini di faccine rese accessibili grazie all’uso di testi alternativi.

<img src="images/smilies/tupitupi.gif"

alt="[Sono felice!]" border="0">

<img src="images/smilies/biggrin.gif"

alt="[Sorriso a 32 denti]" border="0">

<img src="images/smilies/zizi.gif"

alt="[Davvero!]" border="0">

Abbiamo dunque due possibili meccanismi, da utilizzare per rendere accessibili le faccine, entrambi basati su un criterio di conversione automatica delle sequenze di caratteri immesse dagli autori: l’uso di immagini fornite di appropriati testi alternativi e l’uso dell’elemento ABBR, con un valore di title che fornisca il testo sostitutivo per l’arte ASCII.

L’uso di immagini per questo scopo non ha vere controindicazioni, se si esclude la piccolezza delle icone che rappresentano le faccine, che possono risultare perciò poco visibili per un ipovedente.

L’uso di ABBR ha invece due controindicazioni, di cui la seconda più importante della prima:

  1. dal punto di vista semantico, è difficile considerare una faccina come un’abbreviazione. È più che altro la metafora di un sentimento, un simbolo. L’uso di ABBR per fornire un’alternativa accessibile alle faccine rappresenta pertanto un accomodamento, per quanto ragionevole, dal momento che HTML non possiede altri elementi, all’infuori di ABBR e ACRONYM, in grado di fornire un testo alternativo a una sequenza di caratteri;
  2. per impostazione predefinita, JAWS e Window-Eyes, gli screen reader più usati, ignorano la presenza di espansioni per acronimi e abbreviazioni (cioè i valori di title degli elementi ACRONYM e ABBR). Bisogna modificare le impostazioni dei due programmi, affinché i testi alternativi alle faccine possano essere letti al posto delle sequenze non significative di caratteri. Tuttavia, solo gli utenti più avveduti modificano tali impostazioni: chi ignora persino che esistano cose come gli elementi HTML per le abbreviazioni, non lo farà (si veda sull’uso di ABBR e ACRONYM il commento al punto di controllo 4.2 nel Capitolo 7).

Per quanto riguarda il secondo punto, lo abbiamo citato per dovere di completezza: riteniamo, infatti, che non si debba rinunciare a una buona soluzione di accessibilità, se è adeguatamente supportata dai programmi utente, solo perché una percentuale di utenti è incompetente nell’uso dei software che adopera abitualmente per navigare (JAWS, per esempio, supporta le espansioni di ABBR e ACRONYM fin dall’ormai lontana versione 4.51). Al massimo, si può prevedere di inserire, nei siti che forniscono un testo alternativo alle faccine per mezzo di ABBR, un avviso che spieghi agli utenti di screen reader come impostare i loro programmi, affinché leggano le espansioni di abbreviazioni e acronimi.

[Inizio approfondimento] Una precisazione sull’uso di ABBR

Nel commento al punto di controllo 4.2 (Capitolo 7), avevamo sconsigliato di usare ABBR e ACRONYM, a favore dell’inserimento delle forme estese delle sigle direttamente nel testo visibile dei documenti. Qui consigliamo, invece, di usare ABBR per rendere accessibili le faccine. La cosa è meno contraddittoria di quanto possa sembrare. L’uso di ABBR e ACRONYM ha, è vero, una pessima resa visuale ed è mal supportato dai browser grafici (e questo è il motivo per cui nel Capitolo 7 ne sconsigliavamo l’uso), ma non ha un impatto altrettanto negativo sugli screen reader, che invece lo supportano. Poiché la marcatura delle faccine con ABBR serve esclusivamente agli utenti di screen reader, possiamo ritenerla una soluzione utile per l’accessibilità. [Fine approfondimento]

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.