Fornire chiari meccanismi di navigazione

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 :

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

• barre di navigazione – una barra di navigazione è un insieme di collegamenti alle parti più importanti di un documento o di un sito;
• mappe del sito – una mappa del sito fornisce una visione globale dell’organizzazione di una pagina o di un sito;
• sommari – un sommario generalmente elenca (e collega a) le sezioni più importanti di un documento.

Punto di controllo 13.1, priorità 2

Mai più “clicca qui”!

Il paragrafo 6.1 Link text 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

Mappe ragionate al posto dei link nel testo

In Progettare e scrivere per Internet (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 . 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.

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.

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

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

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/ . Sintetizzando, le questioni sono essenzialmente tre:

• nei browser grafici l’unico modo per leggere il contenuto di title è passare col mouse sul collegamento, il che rende l’accesso alle informazioni in esso presenti dipendente dal dispositivo;
• i contenuti di title vengono resi nei browser grafici come piccoli messaggi a comparsa (tooltip): dei fumetti su sfondo giallo, non ridimensionabili, che rimangono visibili sullo schermo per qualche secondo e poi scompaiono; alcuni browser (Netscape, Firefox) li troncano addirittura, se superano i 75 caratteri. Ciò ne rende la lettura particolarmente difficoltosa, penalizzando soprattutto gli ipovedenti, che, se usano un ingranditore di schermo con un alto fattore d’ingrandimento, possono leggere solo due o tre parole per volta del contenuto di title. Il resto, se c’è, finisce fuori dell’area ingrandita dal software (se però l’utente si sposta dove c’è il testo non ancora letto, il mouse esce fuori dall’area del link, cosa che fa scomparire il tooltip prima che possa venir letto);
• le impostazioni predefinite degli screen reader non prevedono la lettura dei contenuti di title, ma solo quella del testo visibile dei collegamenti; la maggior parte degli utenti di screen reader non modifica le impostazioni predefinite e perde dunque la possibilità di ascoltare le informazioni accessorie contenute in title (un attributo di cui, del resto, è lecito ignorare l’esistenza, a meno che non ci si occupi per lavoro di HTML e affini).

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.

Inizio pagina

Punto di controllo 13.2, priorità 2

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

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.

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

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:

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

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 :

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.

• XML fornisce una sintassi di massima per documenti strutturati, ma non impone alcun vincolo semantico sul significato di questi documenti.
• XML Schema è un linguaggio per restringere la struttura dei documenti XML e che estende anche XML per mezzo dei datatypes.
• RDF è un modello di dati per oggetti (“risorse”) e per le loro relazioni; fornisce una semplice semantica per questo modello di dati, che può essere rappresentato in una sintassi XML.
• RDF Schema è un vocabolario per descrivere le proprietà e le classi di risorse RDF, con una semantica per gerarchie generalizzate di tali proprietà e classi.
• OWL aggiunge un vocabolario più ampio per descrivere proprietà e classi: tra le altre, relazioni tra le classi (per esempio: disgiunzione), cardinalità (per esempio: “esattamente uno”), uguaglianza, una più ricca classificazione di proprietà, caratteristiche di proprietà (per esempio: simmetria) e classi numerate.

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 (“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:

• classi (oggetti in generale) nei vari domini d’interesse;
• le relazioni che possono esistere tra gli oggetti;
• le proprietà (o attributi) che tali oggetti possono avere.

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

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 , sono stati i seguenti.

• Primi 5 fattori d’irritazione:
  • mancanza di un motore di ricerca interno;
  • nessuna mappa del sito;
  • mancanza di link interni per saltare i menu e per tornare a inizio pagina;
  • finestre pop-up;
  • impossibilità di modificare la dimensione dei caratteri e il contrasto dei colori.
• Le 5 caratteristiche più utili:
  • presenza di un motore di ricerca interno;
  • presenza di una mappa del sito;
  • collegamenti chiari e facilmente riconoscibili;
  • strumenti di navigazione interni al documento;
  • possibilità di personalizzare l’aspetto visivo della pagina e la dimensione dei caratteri.

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

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

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

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

Inizio pagina

Punto di controllo 13.4, priorità 2

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 è 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).

Inizio pagina

Punto di controllo 13.5, priorità 3

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.

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] 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 , è 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]

Inizio pagina

Punto di controllo 13.6, priorità 3

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 ):

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):

• includere un collegamento per consentire di saltare i link di navigazione;
• fornire un foglio di stile che permetta agli utenti di nascondere il gruppo di link di navigazione;
• usare l’elemento MAP di HTML 4.01 per raggruppare i collegamenti, quindi identificare il gruppo per mezzo dell’attributo title.

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.

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.

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.

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 .

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”).

Una ricerca completa sull’argomento è stata realizzata da Bob Easton nel 2005 ed è consultabile sul blog Access Matters . 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

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.

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 quadra – link di questa pagina: salta il menu – chiusa parentesi quadra – aperta parentesi quadra – link: home – chiusa parentesi quadra – aperta parentesi quadra – link: 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

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 ):

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.

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

Inizio pagina

Punto di controllo 13.8, priorità 3

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

Il paragrafo 5.1 delle Tecniche di base per le WCAG 1.0 è 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.

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 . Il codice di marcatura è, in entrambi i listati, una nostra aggiunta.

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

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.

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

• start – designa il primo documento della collezione;
• next – designa il documento successivo a quello corrente, nella sequenza lineare che va dal primo all’ultimo della raccolta (potrebbe essere, per esempio, il capitolo 3 di un libro, se quello corrente è il 2);
• prev – designa il documento precedente a quello corrente, con modalità analoghe a quelle indicate per next;
• contents – rimanda a un documento usato come sommario dei contenuti (per esempio la pagina iniziale delle Specifiche HTML 4.01, che contiene i link a tutti gli argomenti trattati nel resto della Raccomandazione);
• index – rimanda a un indice analitico dei contenuti;
• glossary – rimanda a un glossario di termini per il documento corrente;
• copyright – rimanda alla nota sul diritto d’autore per la collezione di cui fa parte il documento corrente;
• chapter – rimanda a un documento che rappresenta un capitolo in una collezione di documenti;
• section – rimanda a una sezione, intesa come sottoinsieme di un capitolo;
• subsection – rimanda a una sottosezione, cioè a un sottoinsieme di una sezione;
• appendix – rimanda a un documento che svolge il ruolo di appendice all’interno della raccolta;
• help – rimanda a un documento che ha valore di guida o di aiuto;
• bookmark – rimanda a un segnalibro, cioè a un punto preciso all’interno di uno qualsiasi dei documenti della collezione.

Il Listato 18.3 mostra un esempio, ricavato dalla traduzione italiana delle Specifiche CSS2 (capitolo 11 Effetti visivi ), 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).

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.

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.

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

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

Punto di controllo 13.10, priorità 3

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.

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 . Presentiamo qui l’esempio, dopo averlo adattato all’italiano:

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 .

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

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="").

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 .

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.

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.

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

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

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

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.

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 pagina