Fornire alternative equivalenti per i contenuti uditivi e visivi

La prima linea guida delle WCAG 1.0 è probabilmente la prima anche per importanza. Contiene punti di controllo che suggeriscono di fornire alternative equivalenti per una lunga serie di contenuti (oggetti grafici e di programmazione, script, frame, contributi multimediali ecc.), la cui fruizione diretta è, o può essere, impossibile per utenti con disabilità.

Fornire alternative equivalenti è uno dei nodi centrali dell’accessibilità, perché è il modo in cui i contenuti possono essere resi disponibili a tutti, indipendentemente da disabilità e limiti di dotazione tecnologica. È importante perciò capire bene cosa si intende per “equivalente”, almeno nell’ambito delle WCAG 1.0.

Il concetto di equivalente

Il concetto di “equivalente” è trattato ampiamente nell’introduzione e nel glossario delle WCAG 1.0. Eccone la definizione, così come risulta dal Glossario.

Un contenuto è “equivalente” a un altro contenuto quando ha essenzialmente la stessa funzione o lo stesso scopo nella presentazione fornita all’utente. Nel contesto di questo documento, l’equivalente deve svolgere per una persona con disabilità (nella misura in cui ciò sia fattibile, dati la natura della disabilità e lo stato della tecnologia) essenzialmente la stessa funzione che svolge il contenuto primario per una persona senza disabilità. Per esempio, il testo “La luna piena” dovrebbe convogliare la medesima informazione di un’immagine della luna piena, quando presentati agli utenti. Si noti che un’informazione equivalente si concentra sul compito di svolgere la stessa funzione. Se l’immagine è parte di un collegamento ipertestuale e la sua comprensione è cruciale per indovinare la destinazione del collegamento, un equivalente deve dare agli utenti anche un’idea della destinazione del collegamento.

È un punto di fondamentale importanza: un equivalente testuale non deve limitarsi a descrivere il contenuto dell’oggetto grafico che sostituisce, ma deve sforzarsi di tradurre in parole la funzione che ha l’oggetto all’interno del documento.

In certi casi, però, la funzione può essere resa solo insieme a un’accurata descrizione:

Come parte dello svolgere la stessa funzione di un contenuto, un equivalente può implicare una descrizione di quel contenuto (cioè di come esso appare alla vista o all’udito). Per esempio, al fine di consentire agli utenti di comprendere le informazioni veicolate da un grafico complesso, gli autori dovrebbero descrivere le informazioni visuali in esso presenti.

La chiave di volta del meccanismo degli equivalenti è il testo scritto: solo il testo, infatti, si presta a essere veicolato senza perdita d’informazioni attraverso i diversi tipi di dispositivi utilizzati da utenti con disabilità. Il testo scritto è perciò lo strumento base per fornire informazioni equivalenti:

Poiché i contenuti testuali possono essere presentati agli utenti come discorso pronunciato da un sintetizzatore, come braille e come testo visualizzato su un monitor, queste linee guida richiedono equivalenti testuali per le informazioni grafiche e uditive. Gli equivalenti testuali devono essere scritti in modo da convogliare tutte le informazioni essenziali.

Tuttavia, per alcuni tipi di disabilità gli equivalenti testuali non sono una soluzione accessibile. In determinati casi possono servire degli equivalenti non testuali:

Gli equivalenti non testuali (per esempio: una descrizione vocale di una presentazione visiva oppure un video di una persona che narra una storia usando il linguaggio dei segni come equivalente di un racconto scritto ecc.) aumentano l’accessibilità per le persone che non possono accedere alle informazioni visive o al testo scritto, tra cui molti individui con cecità, disabilità cognitive, disabilità dell’apprendimento e sordità.

La complessa definizione di equivalente si sofferma a questo punto sui modi in cui possono essere presentate all’utente informazioni equivalenti:

Le informazioni equivalenti possono essere fornite in una molteplicità di modi: attraverso attributi (per esempio: un testo usato come valore dell’attributo alt in HTML e SMIL), come parte del contenuto di un elemento (per esempio: OBJECT in HTML), come parte del contenuto testuale di un documento o per mezzo di un documento collegato (per esempio: referenziato dall’attributo longdesc in HTML o da un link che rimanda a una descrizione). A seconda della complessità dell’equivalente, può essere necessario combinare le tecniche (per esempio: usare alt per un equivalente breve, utile per i lettori esperti, in aggiunta a longdesc, che rimanda a più complete informazioni, destinate ai lettori alle prime armi).

Un tipo particolare di equivalente è la trascrizione testuale, che ha la funzione di rendere accessibili i contenuti multimediali a chi non può fruirne nella forma originale.

Una trascrizione testuale è un equivalente testuale di informazioni audio, che include le parole pronunciate e suoni non verbali come gli effetti sonori. Un sottotitolo [caption] è una trascrizione testuale della traccia audio di una presentazone video, sincronizzata con le tracce video e audio. I sottotitoli sono resi in genere visivamente mediante sovrimpressione al video: di ciò beneficia chi è sordo o duro d’orecchi e chiunque non possa ascoltare l’audio (per esempio, perché si trova in una stanza affollata). Una trascrizione testuale assemblata [collated] combina (assembla) i sottotitoli con descrizioni testuali delle informazioni video (descrizioni delle azioni, del linguaggio del corpo, della grafica e dei cambi di scena nella traccia video). Questi equivalenti testuali rendono le presentazioni accessibili a chi è sordocieco o a chi non può riprodurre filmati, animazioni ecc. Rendono inoltre le informazioni disponibili ai motori di ricerca.

Un altro tipo di equivalente, adatto specificatamente ai contenuti video, è la descrizione uditiva:

Un esempio di equivalente non testuale è una descrizione uditiva degli elementi chiave, dal punto di vista visuale, di una presentazione. La descrizione può essere sia una voce umana preregistrata sia una voce sintetica (registrata o generata in tempo reale). La descrizione uditiva è sincronizzata con la traccia audio della presentazione, usualmente con le pause naturali della traccia. Le descrizioni uditive includono informazioni circa le azioni, il linguaggio del corpo, la grafica e i cambi di scena.

Riassumendo: un equivalente ha la funzione di “tradurre” i contenuti che possono essere percepiti solo attraverso un senso, in modo tale che possano essere percepiti attraverso sensi differenti. Un’immagine, per esempio, si rivolge esclusivamente alla vista: fornire un equivalente testuale permette di rendere la funzione di quell’immagine accessibile anche attraverso l’udito e il tatto (l’equivalente testuale può infatti essere letto da una sintesi vocale oppure trasmesso a un display Braille).

Ma non è solo una questione di percezione. Un video che traduce in linguaggio dei segni un testo scritto non si sta rivolgendo a un senso diverso dalla vista: anche il testo scritto può essere letto infatti con gli occhi. Si sta rivolgendo piuttosto a capacità cognitive differenti: per esempio quelle di utenti sordi dalla nascita, che spesso non sono in grado di comprendere agevolmente un testo scritto.

Esistono, insomma, diversi tipi di equivalente: il loro scopo è rendere possibile sia la percezione sia la comprensione dei contenuti da parte degli utenti. Il testo scritto, benché sia la forma di equivalente più potente e flessibile, a volte non basta allo scopo. Nel produrre contenuti accessibili, autori e sviluppatori dovrebbero sempre chiedersi: questo contenuto a quali sensi e a quali capacità cognitive si rivolge? C’è qualche categoria di utenti che – dato il tipo di contenuto – rimane automaticamente esclusa? Se la risposta è sì, il passo successivo deve essere produrre un equivalente adatto, nei limiti del possibile, alle caratteristiche percettive e cognitive degli utenti che sarebbero esclusi.

Inizio pagina

Punto di controllo 1.1, priorità 1

Testi alternativi per le immagini

Il punto di controllo 1.1 invita gli sviluppatori a considerare attentamente la natura di tutti i contenuti presenti in un documento, suddividendoli tra testuali e non testuali.

Ogni contenuto non testuale necessita in teoria di un testo alternativo, ma occorre fare molta attenzione alla funzione che il contenuto svolge all’interno del documento. Ciò vale innanzitutto per le immagini, che sono il tipo di contenuto non testuale più comune.

Equivalenti per immagini decorative e di servizio

Anni fa, quando cominciavano a nascere i primi siti sviluppati seguendo le raccomandazioni delle WCAG, capitava di incontrare pagine infarcite di testi alternativi un po’ surreali, del tipo: alt="pallino rosa" oppure alt="immagine spaziatrice". Tutto ciò è solo “rumore”, cioè fastidio e perdita di tempo, per chi ascolta con uno screen reader.

Si può fare a meno allora dell’attributo alt, almeno in certi casi? Non proprio. Per ogni immagine, qualsiasi sia il suo ruolo, è essenziale inserire sempre l’attributo alt. Progettato specificamente per l’accessibilità, questo attributo ha lo scopo di fornire un testo alternativo per oggetti non testuali: se in un elemento IMG manca l’attributo alt, browser testuali e sintetizzatori vocali vanno in cerca di informazioni sostitutive e, nella maggior parte dei casi, riportano il nome del file grafico dell’immagine, con un effetto che può essere noioso e soprattutto può confondere.

Tuttavia, nel caso si tratti di immagini decorative o di servizio (come gli spaziatori trasparenti), è altrettanto essenziale che l’attributo alt sia lasciato vuoto: quando una tecnologia assistiva incontra un alt vuoto, evita di fornire all’utente qualsiasi informazione sull’elemento che lo contiene, con guadagno di tempo e di chiarezza.

I testi alternativi devono rendere in parole solo i contenuti non testuali che abbiano un valore realmente informativo: pallini rosa e immagini spaziatrici non appartengono a questa categoria.

Qualora si usi un’immagine come indicatore di un punto-elenco, consigliamo di usare anche in questo caso l’ alt vuoto. È vero che l’immagine usata per marcare un punto-elenco ha un valore funzionale e non solo decorativo. Tuttavia inserire testi alternativi come alt="pallino segnaposto" o alt="-" non aggiunge nessuna informazione al punto-elenco (la sintesi vocale leggerebbe “trattino”) o alt="*" (“asterisco”). Si rischia anzi di creare solo noia o confusione nell’ascoltatore. La soluzione migliore per l’accessibilità è, invece, strutturare l’elenco con gli opportuni marcatori per le liste (OL, UL, DL), usando i CSS per definire l’immagine adoperata come marcatore.

Meno che mai è accettabile di inserire nell’ alt di un’immagine segna-punto lo stesso testo visibile del relativo punto elenco (in passato capitava spesso, e talvolta capita anche oggi): si crea solo una ridondanza, che rischia di essere spaventosamente noiosa per l’ascoltatore.

Inizio pagina

Testi alternativi per i logo

L’attributo alt può essere utilizzato in associazione con quattro elementi: APPLET, AREA, IMG e INPUT.

Per quanto riguarda l’uso di alt con IMG, gli equivalenti testuali possibili sono numerosi, a seconda della funzione svolta dall’immagine nel documento.

Un caso tipico è quello dei logotipi o, più brevemente, logo, cioè dei marchi che identificano aziende, enti, organizzazioni, iniziative, associazioni ecc. Se un logo contiene il nome dell’azienda o dell’ente a cui appartiene e non c’è un link applicato sull’immagine che lo rappresenta, la cosa migliore è riportare come equivalente testuale il nome stesso dell’azienda o dell’ente. È la soluzione usata per esempio nella home page del sito del W3C.

Tale soluzione non è più adeguata, però, se il nome dell’azienda o dell’ente compare nel testo visibile, accanto al logo. In quel caso, inserire il nome anche nel testo alternativo dell’immagine porta a una duplicazione dello stesso contenuto, che è da evitare. Meglio allora inserire un alt vuoto.

Un caso un po’ diverso è quello in cui il logo è un’immagine che contiene solo la sigla dell’ente e si trova accanto al nome per esteso, in testo normale. È il caso del sito del Dipartimento per le politiche fiscali , il cui nome, in testo semplice, è preceduto da un’immagine con il logo: una specie di falce di luna che contiene la sigla “DPF”.

Sul sito del Dipartimento, il testo alternativo usato per l’immagine è “logo DPF”. Noi consigliamo, più semplicemente, alt="DPF". A chi usa un sintetizzatore vocale non interessa tanto di sapere che c’è un’immagine e che l’immagine è un logo. Interessa piuttosto che l’ascolto in successione dei vari pezzi formi un insieme coerente (“DPF, Dipartimento per le politiche fiscali” suona come una sigla seguita dalla sua espansione).

Un logo merita una descrizione testuale di ciò che è, e di ciò che vi è raffigurato, solo se l’autore intende attirare espressamente l’attenzione su di esso.

Avrebbe meritato, per esempio, una descrizione del contenuto, che invece manca, il logo dell’iniziativa “Parlamento pulito!”, sponsorizzata dal blog di Beppe Grillo. Tale logo, riportato in Figura 4.3, è presentato in una pagina che descrive l’iniziativa , nata per sollecitare una legge che svuoti il Parlamento italiano dai condannati in via definitiva. Attualmente l’elemento IMG che richiama il logo ha un valore di alt non significativo, che corrisponde al nome del file grafico: Parlamento_pulito_big.JPG. A beneficio di chi non può vedere, sarebbe stato invece preferibile inserire un valore di alt in grado di comunicare il senso ideale dell’iniziativa, che il logo vuole trasmettere.

Un logo corredato da descrizione testuale del contenuto deve essere comunque un’eccezione, non la regola. La descrizione va inserita solo laddove è giusto richiamare l’attenzione del lettore sul logo.

Un caso ancora differente, e molto comune, è quello in cui su un logo è applicato un collegamento ipertestuale (che rimanda di solito alla pagina principale del sito associato al logo). La prima cosa da fare è distinguere se si tratta di collegamenti interni o esterni al sito corrente. Nel caso di collegamenti interni, basterà inserire come testo alternativo il nome associato al logo e/o la destinazione del link (home page, prima pagina, o quel che sia). Nel caso di collegamenti esterni, è opportuno invece specificare nel testo alternativo che il link rimanda a un altro sito: si tratta di un’importante indicazione di orientamento per chi non può aiutarsi con riferimenti visivi.

Confrontiamo quanto detto con due casi tratti dalla realtà del Web, uno di collegamento interno e uno di collegamento esterno al sito. Il primo esempio riguarda il codice di marcatura per il logo dell’INPS, l’Istituto Nazionale Previdenza Sociale , presente nelle pagine interne del sito omonimo.

Nel testo alternativo “Link Home Page” c’è sicuramente un elemento ridondante: è la parola “link”. Tutti gli screen reader avvertono l’ascoltatore che un certo testo fa parte di un collegamento: dunque non è necessario ripetere l’informazione nel testo alternativo. Per quanto riguarda il resto, la scritta “Home page” può essere considerata una scelta valida, purché sia inequivocabilmente chiaro:

1. in che sito l’utente si trova;
2. che il link rimanda alla home page del sito corrente (è cioè un link interno).

Nel caso dell’INPS, non c’è possibilità di equivoco perché il logo di Figura 4.4 è il primo contenuto di una serie di documenti che hanno tutti (erroneamente, perché è troppo generico) il titolo “INPS – Istituto Nazionale Previdenza Sociale”. Se vi fosse stata, invece, possibilità di dubbio, un testo alternativo migliore sarebbe stato “INPS, home page”, o qualcosa di simile.

Vediamo ora un esempio di collegamento esterno, tratto dalle pagine di secondo livello di una versione non più online del sito del Governo italiano. Alla fine del menu verticale di sinistra, era presente in queste pagine un loghino con la scritta “W3C Member”, collegato alla home page del sito del W3C.

Il testo alternativo “La Presidenza è membro del W3C” rende perfettamente il significato del logo; è tuttavia incompleto, perché non dice nulla sul fatto che il logo è un collegamento che rimanda al sito del W3C. Una simile informazione non può essere taciuta, perché l’utente che ascolta la lettura di una sintetizzatore vocale non ha altra fonte che quel testo alternativo, per sapere dove porta il link applicato all’immagine. Manca infatti un testo visibile inserito nell’elemento A e il valore dell’attributo title solitamente non viene letto dagli screen reader (sul rapporto tra title e accessibilità, si veda il paragrafo “Il grande incompiuto: l’attributo title” nel Capitolo 16). Ed è proprio il contenuto di title che sarebbe stato perfetto come valore di alt per l’elemento IMG. Dopo una prima parte uguale al contenuto di alt, il testo di title aggiunge: “Visita il sito del World Wide Web Consortium”. Ecco l’informazione che mancava! Inserirla nel valore di alt, sarebbe stato il modo migliore per indicare agli utenti di screen reader la destinazione del collegamento posto sull’immagine del logo.

È opportuno a questo proposito citare nuovamente (lo avevamo già fatto nel paragrafo “Il concetto di equivalente”) una precisazione contenuta nel glossario delle WCAG 1.0:

Se l’immagine è parte di un collegamento ipertestuale e la sua comprensione è cruciale per indovinare la destinazione del collegamento, un equivalente deve dare agli utenti anche un’idea della destinazione del collegamento.

Inizio pagina

Testi alternativi per voci di menu realizzate con IMG

Rendere voci di menu e pulsanti di modulo come oggetti grafici crea un duplice problema di accessibilità:

1. testi resi come oggetti grafici non sono ingrandibili in molti browser;
2. è necessario non dimenticarsi di inserire un testo alternativo per ciascuno di essi, altrimenti gli utenti di screen reader e browser testuali potrebbero avere serie difficoltà a utilizzare menu e moduli.

Per tali ragioni è senz’altro più pratico e accessibile realizzare voci di menu e pulsanti di modulo in modalità non grafica, soprattutto in considerazione del fatto che il diffuso supporto per i CSS consente oggi di ottenere effetti stilistici di notevole impatto anche formattando del semplice testo.

Tuttavia l’uso di immagini grafiche per menu e moduli è ancora relativamente diffuso. È dunque opportuno fornire indicazioni sui testi alternativi da utilizzare in tre scenari piuttosto comuni:

• menu di navigazione fatti con una serie di elementi IMG ;
• menu di navigazione costruiti su mappe immagine (elementi AREA);
• pulsanti di invio grafici (elementi INPUT).

Dopo l’esempio del Comune di Marcianise, (Capitolo 1, La navigazione ‘invisibile’), un altro esempio di menu di navigazione costruito con una serie di elementi IMG privi di testi alternativi ci è dato dal sito web del Comune di Venafro , in provincia di Isernia.

Come si può vedere dal confronto delle due schermate in Figura 4.6, le voci di menu, che sono immagini GIF, non sono leggibili in Lynx, cioè in modalità solo testo. Al posto dei testi alternativi mancanti, sono visibili, tra parentesi quadre, i nomi dei file GIF relativi a ciascuna voce. A dire il vero, la destinazione di parecchi link può essere desunta dai nomi dei file GIF, che ricalcano grosso modo il testo della corrispondente voce di menu: segnaguasti.gif corrisponde per esempio a “Segnalazione guasti”, certificati.gif corrisponde a “Modulistica-Certificazioni”, e così via. Ma solo un abitante della zona potrebbe capire, per esempio, che oasimortine.gif allude all’Oasi Le Mortine o che il link su bartolomeo.gif apre una pagina che parla del fiume San Bartolomeo. Meno che mai si possono intuire le voci di menu corrispondenti a categorie generali: al posto di “Territorio” l’utente di screen reader o browser testuali trova [frecciatitolo3.gif]; al posto di “Turismo”, [frecciatitolo5.gif].

Che testi alternativi si sarebbero dovuti usare per questo menu di navigazione? Esattamente gli stessi testi che sono visibili in modalità grafica. Perciò, nell’elemento IMG che richiama il file segnaguasti.gif, si sarebbe dovuto inserire alt="Segnalazione guasti"; nell’ IMG che richiama certificati.gif, alt="Modulistica-Certificazioni"; nell’ IMG che richiama frecciatitolo3.gif, alt="Territorio", e così via, per tutte le numerose GIF che compongono il menu. Ciò avrebbe permesso agli utenti di screen reader e browser testuali di trovare un menu di navigazione perfettamente accessibile.

Inizio pagina

Testi alternativi per voci di menu realizzate con AREA

Un’altra situazione relativamente comune è un menu grafico fatto con link posti su una mappa immagine. Un esempio ci è fornito dal menu di navigazione del sito del Comune di Castiglione dei Pepoli , nell’Appennino Tosco-Emiliano.

Le cinque voci “Notiziario”, “Certificati”, “Modulistica”, “Bandi”, “Home page” sono altrettante sezioni rettangolari di una mappa immagine.

Chi ha realizzato il codice riportato nel listato ha inserito opportunamente testi alternativi per ognuno dei cinque elementi AREA. I valori di alt utilizzati riproducono lo stesso testo visibile nelle corrispondenti aree della mappa, come è giusto che sia.

L’unico errore che si può notare è la mancanza dell’attributo alt nell’elemento IMG che contiene le immagini delle voci di menu. Ciò genera una carenza d’informazione in modalità solo testo, che è visibile nell’immagine in Figura 4.9 A, evidenziata dall’ovale. Si tratta di un problema analogo a quello descritto per le voci senza alt nel menu grafico del sito del Comune di Venafro: il nome del file intestazione.gif non dice nulla sul fatto che il link che vi è applicato sopra rimanda alle voci di menu mostrate in Figura 4.8. Tra l’altro quelle voci di menu si trovano molto lontano nella sequenza del contenuto, proprio alla fine del documento.

Per rendere accessibile l’immagine sarebbe bastato inserire alt="Menu principale" nell’elemento IMG riportato nel Listato 4.9.

Si noti, per inciso, che la sfilza di [segnapunto_fffbff.jpg], visibile sulla sinistra in Figura 4.9 A, è la noiosa conseguenza della mancanza di alt="" su una serie di immagini di pallini colorati, usate come punti elenco in un successivo menu.

È opportuno ricordare, infine, che l’ordine in cui appaiono le voci “HOME PAGE”, “BANDI” ecc. in Figura 4.9 B è differente dall’ordine di visualizzazione delle corrispondenti voci (partendo da sinistra), nella mappa grafica in Figura 4.8. L’ordine in modalità solo testo dipende, infatti, dall’ordine in cui si succedono gli elementi AREA nel codice di marcatura, mentre l’ordine di visualizzazione in modalità grafica dipende da come è costruita l’immagine che funge da mappa e dai valori posizionali inseriti nell’attributo coords di ogni elemento AREA Nel definire, dunque, l’importanza relativa delle voci di un menu realizzato con una mappa immagine, occorre tener presente che saranno lette per prime da un sintetizzatore vocale le voci i cui corrispondenti elementi AREA compaiono per primi nel codice.

Inizio pagina

Testi alternativi per pulsanti grafici realizzati con INPUT type=“image”

La Figura 4.10 mostra il blocco principale della pagina di Live Search , il nuovo motore di ricerca della Microsoft. Il pulsante che avvia la ricerca è un oggetto grafico, il file search_go.gif, che rappresenta una lente d’ingrandimento, simbolo che sul Web è largamente usato per indicare le funzionalità di ricerca. La pagina è anche adattata all’italiano, come appare dalle voci “Immagini”, “Notizie”, “Mappe”. Non c’è dunque alcun problema d’usabilità per un utente normovedente di lingua italiana.

Com’è invece la situazione per chi naviga con un browser testuale? Lo illustra la Figura 4.11, che mostra lo stesso blocco di Figura 4.10, caricato in Lynx 2.8.6.

Al posto del pulsante con la lente d’ingrandimento, appare la parola “Search”, l’unica in inglese di tutto il blocco. Ciò dipende dalla mancanza di un testo alternativo (che, se ci fosse stato, sarebbe dovuto essere in italiano) all’interno dell’elemento INPUT che richiama il file grafico.

Nel caso di Microsoft Live Search non c’è un vero problema di accessibilità per gli utenti di screen reader, perché il pulsante grafico per avviare la ricerca è collegato a un elemento LABEL, che contiene l’etichetta “Cerca” in italiano. Ma quest’elemento LABEL non sarebbe stato necessario, se fosse stato inserito un equivalente alt="Cerca" all’interno dell’elemento INPUT del Listato 4.10. L’uso di LABEL è infatti appropriato per fornire l’etichetta a campi di immissione testo o a caselle d’opzione e di controllo, mentre gli elementi di modulo che generano pulsanti non ne hanno bisogno: possono usare come etichetta o il valore testuale dell’attributo value oppure, se si tratta di pulsanti grafici, il valore di alt.

Quando non trovano un attributo alt, i programmi utente non grafici cercano nel codice di marcatura informazioni utili da passare al lettore. La più congrua è certamente il valore dell’attributo value. Tuttavia, il valore di value è adoperato di solito per gestire funzioni lato server, per cui non è pratico usarlo come contenuto “mobile”, da cambiare a seconda della lingua del browser: infatti, in Microsoft Live Search, il valore di value per il pulsante che avvia la ricerca rimane Search qualsiasi sia la lingua impostata, mentre il valore dell’elemento LABEL collegato cambia in funzione della lingua. Se manca anche un attributo value, gli screen reader si rivolgono allora al valore dell’attributo src, che contiene il percorso del file che genera il pulsante, nel tentativo di dare all’utente informazioni utili sul contenuto dell’immagine.

Un esempio di pulsante con scritta in testo grafico, ma dotato di testo alternativo, è offerto dal sito web del MIUR, il Ministero dell’Università e della Ricerca .

Come si può notare dalla versione testuale in Figura 4.12 B, al posto del pulsante grafico compare l’etichetta “cerca ora”, grazie alla presenza dell’attributo alt all’interno di INPUT. La soluzione è relativamente corretta dal punto di vista del testo alternativo (perché “cerca ora” e non “cerca” e basta?). È errata, invece, dal punto di vista del posizionamento. Per fare una ricerca, è necessario inserire prima il testo da ricercare e poi premere il pulsante che avvia la ricerca: dunque la casella di immissione del testo avrebbe dovuto precedere, non seguire, il pulsante di invio.

In conclusione, i pulsanti di modulo grafici, cioè quelli generati con type="image", devono avere sempre un valore di alt espresso. Se l’immagine usata come pulsante contiene un testo, il valore di alt migliore è quello che ripete esattamente quel testo; se, invece, il pulsante grafico contiene un simbolo, come la lente d’ingrandimento del motore di ricerca Live Search, il valore di alt deve esprimere in parole – in modo sintetico ma preciso – la funzione rappresentata dal simbolo.

Inizio pagina

Testi alternativi per alcuni tipi di immagini informative

Esamineremo in questo paragrafo alcuni casi tipici di immagini che richiedono un testo alternativo.

Uno dei casi più comuni è quello delle gallerie di immagini (fotografie, disegni ecc.). Il fatto che tali gallerie siano destinate per definizione a un pubblico di vedenti non esime autori e sviluppatori dall’inserire opportuni testi alternativi, che permettano agli utenti di tecnologie assistive quanto meno di orientarsi nel materiale pubblicato e di farsi un’idea di massima dei contenuti delle immagini. I testi alternativi sono addirittura essenziali nei siti di commercio elettronico, che fanno ampio ricorso a gallerie fotografiche come materiale illustrativo di supporto all’acquisto dei loro prodotti: conviene forse perdere dei potenziali acquirenti solo perché non sono in grado di vedere le immagini?

Importanti per l’accessibilità sono soprattutto i testi alternativi inseriti negli indici di miniature (thumbnails), che solitamente danno accesso alla versione ingrandita delle immagini archiviate in una galleria. La mancanza di opportuni testi alternativi rende impossibile distinguere l’una dall’altra le varie miniature di un indice, il che obbliga a procedere faticosamente per tentativi, seguendo a caso i collegamenti posti su ciascuna di esse.

Gli indici di Flickr sono un esempio positivo di raccolte di immagini fornite di testi alternativi.

Flickr ricava automaticamente il valore di alt dal titolo che gli autori impongono alle proprie fotografie. I testi alternativi sono quindi tanto più significativi, quanto più gli autori sono stati stati bravi a “battezzare” i propri scatti. Tuttavia l’ alt generato da Flickr è incompleto, perché non dà alcuna informazione sulla destinazione del collegamento applicato su ciascuna miniatura. A tal fine, anche per non creare una serie di alt noiosamente ripetitivi (per esempio: “Vai alla versione ingrandita della foto X”), una buona soluzione potrebbe essere quella di inserire un avviso all’inizio di ogni pagina indice, per avvertire l’utente che i link sulle miniature aprono versioni ingrandite di ogni foto, con la possibilità di trovare informazioni testuali più dettagliate.

Richiedono un testo alternativo anche le icone che segnalano tipi di contenuto e funzioni ricorrenti di un sito. Un esempio ci è fornito da Liber Liber , noto sito italiano che distribuisce opere di letteratura digitalizzate.

Le icone mostrate in Figura 4.14 A hanno il compito di illustrare all’utente i formati in cui è disponibile l’opera selezionata; il link posto su ognuna di esse permette di visualizzare o scaricare l’opera nel formato indicato dall’icona. Il testo alternativo di ciascuna icona, come si nota dalla schermata di Lynx catturata in Figura 4.14 B, riporta correttamente il formato di file a cui ogni icona è associata.

Il limite della soluzione adottata da Liber Liber, se proprio vogliamo trovarne uno, è che i link sulle icone non sono distinguibili fuori contesto. Se, come capita molto spesso, vi sono nella stessa pagina due o più opere, l’utente che scorre il documento saltando di link in link con uno screen reader non può sapere – nel momento in cui incontra il testo alternativo “RTF + ZIP” – quale opera in formato RTF compresso scaricherà seguendo quel link. Una soluzione potrebbe essere, dunque, quella di modificare gli alt sulle icone in modo da inserirvi il titolo dell’opera. Per esempio: alt="La Città del Sole: HTML + ZIP", alt="La Città del Sole: RTF + ZIP", alt="La Città del Sole: TXT + ZIP".

Altre icone che richiedono un testo alternativo sono quelle usate per segnalare che un collegamento porta a un sito esterno. Un esempio di tali icone, per la verità piuttosto rare nell’uso del Web, è fornito dal sito dell’enciclopedia collaborativa Wikipedia, che pospone ai collegamenti verso siti esterni l’iconcina mostrata in Figura 4.15 A.

Si tratta di una soluzione importante per l’accessibilità, perché dà agli utenti un’informazione molto utile per orientarsi nella navigazione (si vedano in proposito i commenti alla linea guida 13 nel Capitolo 18). Tuttavia l’implementazione seguita da Wikipedia lascia a desiderare, sia per l’accessibilità visuale – l’icona è troppo piccola e ha lo stesso colore dei collegamenti – sia per l’accessibilità non visuale: è generata infatti via CSS, come se fosse un puro elemento di presentazione, il che fa scomparire l’informazione che essa trasporta, se la pagina viene riprodotta con uno screen reader o con un browser testuale (Figura 4.15 B).

Nel sito di Wikipedia il danno generato dalla mancata presentazione dell’informazione in modalità non grafica è ridotto, perché i link verso altri siti sono raggruppati solitamente in un elenco posto alla fine degli articoli, intitolato opportunamente “Collegamenti esterni”. Se, però, i link vengono letti in successione fuori contesto, l’informazione è indisponibile. E altrettanto è indisponibile, se il link esterno si trova all’interno di un testo discorsivo. È importante, allora, che l’icona che segnala un collegamento esterno sia sempre inserita come immagine nel codice di marcatura e sia dotata di un valido testo alternativo (Listato 4.13). È necessario, inoltre, che faccia parte dell’elemento A, altrimenti l’informazione verrà perduta dagli utenti di screen reader che saltano da un link all’altro in rapida successione.

Inizio pagina

Inizio pagina

A che punto un equivalente testuale diventa equivalente?

La domanda nel titolo di questo paragrafo non è un gioco di parole, ma tende a mettere in luce un aspetto molto importante, e spesso trascurato, dell’accessibilità: inserire equivalenti testuali per contenuti non testuali non è solo un fatto tecnico, ma autoriale. In altre parole, non si tratta solo di dominare il codice di marcatura, usando in modo appropriato attributi come alt e longdesc, ma è necessario scrivere testi adeguati alla funzione dell’oggetto non testuale che si vuole rendere accessibile: adeguati in ragione del contesto in cui l’oggetto è inserito e delle capacità di comprensione del pubblico a cui il documento si rivolge. È per questa ragione che, sotto il testo del punto di controllo 1.1, abbiamo indicato anche gli autori di contenuti tra le figure professionali coinvolte nella sua applicazione.

Va inoltre tenuto presente che gli equivalenti testuali non sono classificabili in modo assoluto, ma solo in modo relativo. Cosa vuol dire? Vuol dire che i testi alternativi non possono essere giudicati usando solo due categorie (corretto/sbagliato, accessibile/inaccessibile ecc.). Le categorie possibili sono invece numerose e i loro confini sfumati. Un testo alternativo può essere ottimo, buono, discreto, mediocre, pessimo, impreciso, chiarissimo, leggermente inadeguato, troppo generico, prolisso ecc., a seconda di chi lo valuta e dei termini di riferimento adoperati. Si tratta in ogni caso di giudizi relativi, che pongono i testi alternativi su una scala virtuale che va da “del tutto inadeguato” a “perfettamente adeguato”. Ciò è una conseguenza inevitabile del fatto che gli equivalenti sono per lo più testo discorsivo, non equazioni matematiche: non possono essere valutati per mezzo di una logica a due valori, del tipo vero/falso. Ecco perché, tra l’altro, non esistono software capaci di valutare automaticamente il grado di adeguatezza di un equivalente testuale.

Per dare un appoggio verificabile alla teoria appena espressa, proponiamo un esempio di equivalenti testuali progressivamente migliori per due medesimi oggetti grafici: i simboli di due partiti politici, tratti dal sito del Ministero dell’Interno e relativi a un’elezione europea di qualche anno fa (Tabella 4.1).

Tabella 4.1. Confronto tra testi alternativi progressivamente più adeguati

attributo alt mancante (le tecnologie assistive leggono il nome del file, che è udc_____.jpg) alt="Simbolo della Lega per l'autonomia." alt="" (le tecnologie assistive non danno informazioni sull’immagine) alt="Simbolo di un partito politico." alt="Simbolo del partito UDC." alt="Simbolo dell'UDC, partito della coalizione di centro-destra. Apri l'immagine ingrandita." longdesc="desc_udc.html" Contenuto del file desc_udc.html: Il simbolo dell’UDC, Unione democraticocristiana e di centro, mostra nel mezzo lo scudo crociato, sovrapposto a una vela bianca in campo blu, con la scritta “Libertas” in primo piano, bianca su sfondo rosso. In basso compare la scritta “UDC”, di colore blu.

attributo alt mancante (le tecnologie assistive leggono il nome del file, che è f_deiver.jpg) alt="Simbolo della Lega per l'autonomia." alt="" (le tecnologie assistive non danno informazioni sull’immagine) alt="Simbolo di un partito politico." alt="Simbolo del partito dei Verdi." alt="Simbolo dei Verdi, partito della coalizione di centro-sinistra. Apri l'immagine ingrandita." longdesc="desc_verdi.html" Contenuto del file desc_verdi.html: Il simbolo dei Verdi mostra in alto il sole che ride, giallo in campo verde. Più sotto la scritta “Verdi”, in maiuscolo, in colore verde su sfondo bianco, e in basso i colori dell’arcobaleno, su cui campeggia la scritta “per la pace”.

La situazione descritta al punto 1 della tabella, cioè la mancanza totale di attributi alt sui file immagine, è tra le meno accessibili, perché browser testuali e screen reader propongono all’utente il nome del file grafico, che può non dire nulla sul contenuto dell’immagine: cosa si può capire, per esempio, da un nome come f_deiver.jpg? La mancanza è tanto più grave, se sull’oggetto grafico è applicato un link. In tal caso, screen reader e browser vocali si sforzano di dare all’utente indicazioni utili sulla destinazione del collegamento, leggendo per esempio il contenuto dell’attributo href dell’elemento A applicato all’immagine, con risultati che possono essere noiosissimi da ascoltare, oltre che inaccessibili. Purtroppo ancora oggi sul sito del Ministero dell’Interno le liste dei simboli dei partiti sono impaginate senza usare l’attributo alt sulle immagini (si veda come esempio la pagina http://politiche.interno.it/liste2006/simboli.htm ).

Il punto 2 mostra un testo alternativo sbagliato. La cosa interessante è che nessun software automatico è in grado di accorgersi che “Simbolo della Lega per l’autonomia” non è un’alternativa valida per nessuna delle due immagini a cui è associato. Solo un valutatore umano, almeno per ora, può scoprire simili errori. Gli utenti di tecnologie assistive sono quasi inevitabilmente tratti in inganno dai testi alternativi sbagliati, perché non hanno modo di controllare direttamente la corrispondenza tra immagine ed equivalente.

La situazione al punto 3, cioè l’attributo alt vuoto, può essere giudicata accettabile solo nel caso in cui, nella pagina che contiene la lista dei simboli dei partiti politici, vi sia per ogni immagine una didascalia nel testo visibile. Ciascuna didascalia deve contenere però una descrizione sufficiente a permettere, a chi non può vedere le immagini, di comprendere gli aspetti essenziali del relativo simbolo, a partire, ovviamente, dal nome del partito a cui appartiene.

Al punto 4 appare un valore di alt (“Simbolo di un partito politico”) identico sia per l’immagine con il simbolo dell’UDC sia per quella con il simbolo dei Verdi. È adeguato un simile testo a descrivere la funzione dell’oggetto grafico a cui si riferisce? In astratto è un testo alternativo corretto: i due oggetti grafici sono infatti entrambi simboli di un partito politico. Tuttavia è in rapporto al contesto che questo testo alternativo si dimostra inadeguato. Se, in un documento che contiene i simboli di decine di partiti, diamo come unica informazione quella che ogni immagine rappresenta il simbolo di un partito politico, è evidente che stiamo usando una descrizione inadeguata, perché non consente di distinguere il contenuto di un’immagine dal contenuto di un’altra. È un testo alternativo inadeguato perché troppo generico.

Con il punto 5 arriviamo finalmente a testi alternativi differenti l’uno dall’altro (1. “Simbolo del partito UDC”, 2. “Simbolo del partito dei Verdi”): sono adeguati a creare il minimo livello di distinzione, necessario perché l’utente di tecnologie assistive possa capire quali simboli di partiti politici sono raffigurati nel documento che sta consultando.

È solo, tuttavia, con il punto 6 che i testi alternativi raggiungono un livello di dettaglio sufficiente a essere considerati adeguati all’intenzione di una pagina che contenga i simboli di tutti i partiti politici che si presentano alle elezioni.

Con il punto 5, infatti, l’utente che non vede le immagini, ma legge o ascolta solo i testi alternativi, si ritrova con un mero elenco di nomi di partiti politici. Ma l’intenzione di una pagina web come quella presentata in Figura 4.17 non è di fornire un elenco di nomi di partito, bensì di illustrare i simboli di ciascuno.

È noto con quale cura partiti e coalizioni progettano i simboli in vista delle elezioni: si sforzano, infatti, di rappresentare, per mezzo di scudetti sigle figure motti, i contenuti ideali ai quali fanno riferimento. È essenziale, allora, che i testi alternativi di una pagina che contiene simboli di partiti politici descrivano le caratteristiche peculiari di ciascun simbolo. È solo così che si permetterà a chi non vede di rappresentarsi mentalmente la composizione di quei simboli, di farsi cioè un’idea, sia pure approssimata, dei significati ideali che vi sono associati. L’attributo longdesc è ideale per un simile scopo.

Infine, se su ogni simbolo è applicato un collegamento che porta a una sua immagine ingrandita, allora questa informazione deve essere contenuta nel testo alternativo (oppure – come già suggerito in precedenza – va preparato un unico avviso per i lettori, da anteporre all’intera lista dei simboli).

Inizio pagina

Quando usare alt e quando longdesc

L’ultimo esempio di testo alternativo mostrato nel paragrafo precedente fa riferimento a due attributi per i testi alternativi: alt e longdesc. Il primo, di cui abbiamo già trattato diffusamente, va adoperato per fornire un equivalente testuale breve, il secondo un equivalente lungo. Cosa si debba intendere precisamente per “breve” (short) non è spiegato nelle WCAG 1.0, ma la bozza di lavoro del W3C intitolata Techniques for Accessibility Evaluation and Repair Tools , datata 26/4/2000, suggerisce di creare un file con descrizione lunga, se un testo alternativo supera i 150 caratteri. Nella pratica di sviluppo di siti accessibili, sono comuni i valori di alt compresi tra i 50 e i 100 caratteri. Nulla vieta in realtà di andare oltre tale misura, ma è opportuno chiedersi, di fronte a un valore di alt troppo lungo, se non sia possibile sintetizzarne il testo: chi naviga con uno screen reader predilige quasi sempre la brevità, non gli sproloqui.

Se proprio è necessaria una descrizione dettagliata del contenuto di un oggetto grafico, lo strumento opportuno per fornirla è un file collegato per mezzo dell’attributo longdesc. Questo attributo va inserito all’interno dell’elemento IMG che richiede la descrizione lunga (ma può essere usato anche in associazione con FRAME o IFRAME).

In che caso è necessario allegare una descrizione lunga? Quando l’oggetto grafico ha un contenuto complesso, la cui descrizione è essenziale per aiutare chi non può vederlo a comprendere, o comprendere meglio, il resto del documento. Un caso tipico sono i grafici, all’interno di documenti che presentano schemi costruttivi o analisi statistiche.

Per chiarire meglio il concetto, consideriamo il seguente brano, tratto da un interessante articolo sulla distruzione delle risorse ittiche mondiali, dal sito web Eco Alfabeta :

La  FAO sta monitorando circa 600 diverse specie ittiche che vengono comunemente pescate nei mari, nei laghi e nei fiumi di tutto il mondo. Il grafico qui a fianco illustra la situazione attuale. Sembra abbastanza evidente che il picco non riguarda solo la produzione di petrolio [...] I tre quarti delle specie di pesce sono ormai pienamente sfruttate o troppo sfruttate, per cui non esiste più alcuna possibilità di espansione della pesca.

Il testo fa riferimento a un grafico associato all’articolo e dà per scontato che tutti i lettori possano guardare il grafico e trarne informazioni sulla situazione di sfruttamento delle 600 specie ittiche monitorate dalla FAO. Le cose non sono così semplici. Il grafico è un file immagine (riportato in Figura 4.18), a cui si arriva tramite un link applicato su una miniatura inserita nel corpo dell’articolo. Nell’elemento IMG della miniatura è presente un attributo alt non significativo, che contiene semplicemente il nome del file immagine collegato (pesca.jpg); mancano un attributo longdesc o una qualsiasi descrizione visibile del contenuto del grafico.

Volendo rendere accessibile il contenuto del grafico a chi non è in grado di vederlo, possiamo agire su due fronti:

1. inserire nella miniatura che rimanda al grafico un valore di alt significativo;
2. inserire anche un attributo longdesc, che rimandi a una descrizione lunga esauriente.

Proponiamo di seguito una possibile descrizione lunga, da usare come contenuto del file grafico_FAO.html, referenziato dall’attributo longdesc.

Grafico a torta che mostra le percentuali di sfruttamento di 600 specie ittiche, monitorate dalla FAO. Le percentuali evidenziate nel grafico sono le seguenti:

• specie totalmente sfruttate: 52%;
• moderatamente sfruttate: 20%;
• sovrasfruttate: 17%;
• in esaurimento: 7%;
• sottosfruttate: 3%;
• in recupero: 1%.

L’alternativa a longdesc: il D-link

Il D-link o description link è un collegamento ipertestuale applicato su una lettera “D”, racchiusa di solito tra parentesi quadre, posta accanto all’oggetto grafico da descrivere. Il link rimanda a un file esterno che contiene la descrizione lunga dell’oggetto grafico. Se nell’elemento che carica l’immagine è presente anche un attributo longdesc, il D-link avrà la medesima destinazione di longdesc.

Volendo aggiungere un D-link accanto all’immagine del grafico in Figura 4.18, dovremmo utilizzare un codice di marcatura come il seguente.

Lo scopo del D-link è fornire un’alternativa universalmente supportata all’attributo longdesc. Negli anni a cavallo dell’uscita delle WCAG 1.0, infatti, il supporto di screen reader e browser vocali per longdesc era praticamente nullo, per cui l’uso del D-link era una necessità. Oggi per fortuna la situazione è nettamente migliorata. Le ultime versioni delle tre più diffuse tecnologie assistive per non vedenti – cioè JAWS, Window-Eyes e Home Page Reader – supportano tutte e tre il collegamento a una risorsa esterna per mezzo di longdesc.

Si può allora cominciare a fare a meno del D-link? Dipende. Non è possibile escludere a priori che tra il proprio pubblico non vi siano utenti che usano programmi obsoleti o comunque privi di supporto per longdesc. È una scelta di chi pubblica contenuti sul Web propendere per la soluzione più moderna (longdesc), per quella più universale (il D-link) o per entrambe.

Una forma particolare di description link è il D-link invisibile, in cui il collegamento viene applicato su una GIF trasparente da 1 pixel. Lo scopo, in questo caso, è di avere i vantaggi di un link inserito nel corpo del documento (cioè la navigabilità da tastiera per gli utenti di screen reader), senza avere gli svantaggi del D-link, ovvero la presenza esteticamente sgradevole di una “D” accanto alle immagini che necessitano di una descrizione lunga. Tuttavia le Tecniche HTML per le WCAG 1.0 (paragrafo 7.2.1, Invisible D-Links) bollano questa soluzione come deprecata, a vantaggio dell’uso dell’attributo longdesc.

Inizio pagina

Soluzioni per l’accessibilità dei CAPTCHA

Tra gli oggetti grafici che necessitano assolutamente di un equivalente sono da annoverare le implementazioni grafiche dei cosiddetti CAPTCHA: sorta di disegni ingarbugliati, all’interno dei quali solo un utente umano, dotato peraltro di una buona vista, può riuscire a riconoscere la serie di lettere e/o numeri, che deve essere ricopiata senza errori in un apposito campo modulo, per completare con successo l’iscrizione a uno dei tanti servizi web basati su questo sistema.

Senza ripetere le cose già dette nel Capitolo 1 (nel paragrafo O vedi o non accedi), cerchiamo di capire ora che tipo di equivalente può essere prodotto, per garantire da un lato l’accessibilità dei CAPTCHA, dall’altro la preservazione della loro utilità, cioè la funzione di filtro che impedisce ai robot di iscriversi a servizi pensati per gli umani.

La soluzione più immediata, cioè un attributo alt contenente esattamente la serie di caratteri rappresentati graficamente nel CAPTCHA, non è praticabile, perché sarebbe molto facile, per i programmatori di robot, istruire le loro maliziose creature a usare il valore di alt come sequenza per superare il filtro.

Alcuni importanti fornitori di servizi sul Web, come per esempio Yahoo!, non hanno ancora adottato alcun provvedimento per rendere accessibili i loro CAPTCHA grafici. Per ora, dunque, possono iscriversi a Yahoo! senza ricorrere ad aiuti esterni solo utenti in grado di decifrare visivamente una serie di lettere e numeri distorti, come quella mostrata in Figura 4.20 A.

Google e Microsoft hanno invece fatto importanti passi in avanti sulla strada dell’accessibilità, rendendo disponibili agli utenti che desiderano iscriversi ai loro servizi sistemi alternativi ai CAPTCHA, basati sul riconoscimento acustico.

Sia Google sia Microsoft consentono all’utente di tecnologie assistive di ascoltare un file audio, in cui delle cifre vengono lette da una voce in primo piano, mentre altre voci sullo sfondo rendono volutamente disturbato l’ascolto (che comunque rimane pienamente comprensibile, per chi abbia un udito nella media).

Entrambi sono basati su JavaScript, ma, tra i due, ci sembra più accessibile il sistema sviluppato da Google.

Con JavaScript disattivato, l’iscrizione a Google Accounts è ancora possibile, sia pure con la necessità di ascoltare il codice numerico in un’altra finestra e riportarlo poi nella finestra iniziale; al contrario, il tentativo di registrazione a MSN Mail fallisce, con la comparsa di un avviso di Windows Live ID, che annuncia che “per accedere è necessario JavaScript”.

Con JavaScript attivo, il sistema di Google è rapido e diretto: attivando il pulsante con l’icona dell’omino sulla carrozzina (Figura 4.21 A), parte direttamente l’ascolto del codice numerico e l’utente può in contemporanea digitare le cifre nell’apposito campo, che risulta già selezionato. Il sistema di Microsoft (Figura 4.21 B) prevede, invece, l’apertura di una finestra pop-up, contenente un testo di spiegazione. In questa finestra bisogna cercare il pulsante che avvia la riproduzione del codice. Poi occorre selezionare il campo d’immissione e digitare a memoria il codice ascoltato (che viene letto una sola volta, a differenza di Google, che lo ripete due volte). La cosa comoda è che il codice digitato nel campo della finestra pop-up viene automaticamente copiato, alla chiusura della finestra, nel corrispondente campo d’immissione della finestra principale, nella quale si stava compilando il modulo di registrazione.

L’alternativa audio di Google e di Microsoft è sicuramente meglio di niente, ma non ci sembra ancora la soluzione ideale per l’accessibilità dei CAPTCHA, per una serie di ragioni:

1. nel caso del sistema Passport di Microsoft, è necessario che il supporto per gli script sia attivo;
2. l’ascolto del file audio contenente il codice può interferire con l’ascolto della sintesi vocale, che comunque serve tener accesa, per poter continuare la compilazione del modulo d’iscrizione;
3. non è una soluzione valida per chi ha problemi d’udito, oltre che di vista;

Per tutte queste ragioni, riteniamo che la soluzione migliore per l’accessibilità sia quella di eliminare del tutto l’immagine grafica distorta e di affidare la discriminazione tra umani e macchine a CAPTCHA puramente testuali. Ciò permetterebbe non solo di fornire uno strumento accessibile ai non vedenti, ma anche di risolvere i problemi degli ipovedenti e dei ciechi ai colori, che si trovano spesso in grande difficoltà, di fronte a CAPTCHA grafici, in cui le sequenze di caratteri sono talvolta così distorte, da risultare indecifrabili anche per chi ha una buona vista.

Contrariamente a quanto si possa credere, i CAPTCHA testuali, se opportunamente progettati, sono filtri sicuri, almeno quanto lo sono quelli di tipo grafico.

Gli esempi non mancano. Vari gestori di blog, che utilizzano la nota piattaforma WordPress, hanno iniziato da qualche tempo a implementare una soluzione di CAPTCHA accessibile, basata su un semplice calcolo aritmetico, con lo scopo di eliminare la gran massa di spazzatura, inviata a raffica da robot che utilizzano lo stesso modulo usato dai lettori umani per inviare commenti.

La Figura 4.22 mostra un esempio di un simile filtro testuale: si tratta di un normale campo INPUT, la cui etichetta cambia a ogni caricamento della pagina, presentando all’utente una differente addizione. Chi desidera inviare un commento al blog deve scrivere il risultato dell’addizione nella casella alla sinistra dell’etichetta.

Un altro sistema, simile dal punto di vista del codice di marcatura, ma diverso per quanto riguarda il tipo di quesito posto ai lettori, è quello implementato dall’autore di questo libro sul blog Il Pesa-Nervi (Figura 4.23). La differenza è che stavolta non si tratta di risolvere un quesito matematico, ma di scrivere la definizione di un termine. Per essere accessibile, il meccanismo deve richiedere, ovviamente, una definizione che sia alla portata di tutti. Per esempio: “felino domestico, detto anche micio”, dove la parola da inserire è, banalmente, “gatto”.

Perché un CAPTCHA basato su del comune testo visibile nella pagina, dovrebbe riuscire a bloccare la pubblicità indesiderata spedita dai robot?

Può riuscirci, perché un robot non è in grado di capire, nel senso umano del termine, il significato di un testo discorsivo, a meno che non gli vengano fornite tutte le possibili regole interpretative (a tal proposito, si veda il paragrafo dedicato al cosiddetto Web semantico, nel Capitolo 18). Una richiesta apparentemente semplice come quella di trovare il risultato di un’addizione non può essere soddisfatta da un robot, a meno che non sia presentata in una forma sempre uguale. In tal caso, un programmatore potrebbe creare un software che, calcolando la posizione e la struttura delle parole usate nell’etichetta, sappia ricavare la sequenza da inserire nella casella corrispondente. Per ridurre un simile rischio a probabilità trascurabili, è sufficiente programmare le domande dei CAPTCHA in modo tale da formare un numero di combinazioni possibili troppo elevato, perché valga la pena di provare a scrivere un software capace di aggirare il filtro.

Il meccanismo proposto in Figura 4.23 è probabilmente ancora più sicuro. Una definizione può essere assemblata usando termini e costruzioni variabili; inoltre, le parole da indovinare, anche riducendo la scelta a quelle in assoluto più comuni in una lingua, sono pur sempre migliaia, il che rende enormemente difficile il lavoro di chi volesse scrivere un robot programmato per aggirare tale tipo di filtro (compito reso ancor più difficile dal fatto che, nella maggior parte dei casi, i robot “spara-pubblicità” sono scritti da programmatori che parlano altre lingue, rispetto a quella usata nel sito protetto dal filtro). L’esperienza, del resto, sta confermando la previsione: il sistema mostrato in Figura 4.23 è attivo dall’inizio di gennaio 2007 e, da allora, l’invio di commenti-spazzatura si è ridotto esattamente a zero (mentre ne erano arrivati più di mille nei mesi precedenti), senza neppure la necessità di aggiornare periodicamente il semplice quesito proposto ai lettori come filtro.

Un altro CAPTCHA accessibile, basato su un criterio ancora differente, è quello adoperato nel modulo di registrazione di My Opera . Qui non è richiesto all’utente umano alcuno sforzo di deduzione né di decifrazione visiva o acustica. Si tratta semplicemente di ricopiare una breve sequenza di lettere e cifre all’interno della solita casella di immissione testo (Figura 4.24).

È possibile addirittura risparmiare il lavoro di digitazione della sequenza: basta fare una banale operazione di copia e incolla, selezionando il testo dalla pagina e copiandolo bell’e pronto all’interno della casella. Cosa impedisce, allora, a un programmatore di robot di “bucare” un simile sistema, scrivendo un programmino capace di fare quello che un qualsiasi utente umano può fare in due secondi?

Glielo impedisce la soluzione escogitata dai programmatori di Opera, che è probabilmente la migliore tra tutte quelle fin qui esaminate, dal momento che riesce a coniugare perfettamente accessibilità, semplicità di utilizzo e sicurezza. Analizziamo come funziona. Un robot non ha occhi né orecchie. È un software: l’unica cosa che può fare è analizzare il codice di marcatura del documento, alla ricerca di una risposta al quesito usato come filtro. Se nel codice si trovasse una stringa come quella presente nella pagina visibile, allora superare il filtro anche con strumenti automatici sarebbe un gioco da ragazzi. Ma, se esaminiamo il codice di marcatura alla ricerca della stringa-filtro, troviamo qualcosa di apparentemente arcano (Listato 4.16).

La frase e la sequenza di caratteri da copiare (il Please type the text you see: 489b71 di Figura 4.24) appaiono nel codice di marcatura spezzettate in tanti frammenti, racchiusi all’interno di elementi SPAN e separati tra loro da commenti HTML, contenenti a loro volta lunghe serie di cifre. Già così l’insieme appare caotico, al punto da scoraggiare tentativi di scrivere programmi capaci di superare il filtro. Ma, se questo non bastasse, a ogni aggiornamento della pagina cambia l’intera struttura dei gruppi che racchiudono la sequenza da copiare, vanificando qualsiasi speranza di trovare una regolarità. E, senza regolarità, le probabilità di successo per i robot si riducono quasi a zero.

Inizio pagina

Punto di controllo 1.2, priorità 1

Mappe immagine lato server accessibili

Con una mappa lato server l’utente può interagire esclusivamente per mezzo del mouse: il clic su un punto della mappa produce l’invio al server delle coordinate orizzontali e verticali che identificano quel punto; successivamente il server elabora l’informazione, associando alle coordinate ricevute una determinata azione, che viene generata nel browser client. Ecco dunque la necessità di fornire collegamenti testuali ridondanti per ciascuna regione attiva della mappa: in tal modo sarà possibile seguire i collegamenti anche con uno screen reader.

Il documento di tecniche HTML per le WCAG 1.0 suggerisce due modi per realizzare mappe immagine lato server accessibili: il primo consiste nell’inserire i collegamenti testuali ridondanti all’interno di un elemento OBJECT (si veda il commento al punto di controllo 1.5 per un esempio di mappa immagine basata su questo elemento); il secondo nel far seguire i collegamenti testuali all’elemento IMG che contiene la mappa, annunciando la presenza dei collegamenti dall’interno dell’attributo alt associato a IMG, come nel codice seguente, tratto dal documento di Tecniche HTML per le WCAG 1.0, e adattato all’italiano.

Si noti l’uso dell’attributo ismap di IMG, che serve per referenziare le mappe immagine lato server.

C’è per la verità anche una terza tecnica consigliata, ma indica più che altro il fallimento del tentativo di rendere accessibile una mappa immagine lato server: si tratta della raccomandazione, considerata come ultima risorsa, di creare una pagina alternativa accessibile.

Inizio pagina

Punto di controllo 1.3, priorità 1

Audiodescrizioni di contenuti video

Il punto di controllo 1.3 è una delle raccomandazioni più disattese dagli sviluppatori, nonostante abbia priorità 1 e sia dunque ritenuta essenziale per garantire ai contenuti audiovideo quel livello minimo di accessibilità, che serve per non escludere dalla loro fruizione determinate fasce di utenti (in questo caso i non vedenti). È molto difficile, infatti, trovare sul Web dei video corredati da audiodescrizioni, che non siano esempi di “come si fa”, reperibili sui siti di pochi volenterosi e società specializzate in servizi per l’accessibilità.

Ma vediamo di capire innanzitutto cos’è un’audiodescrizione (auditory description). Lo spiega il paragrafo 15 Visual Information and Motion , delle Tecniche di base per le WCAG 1.0:

Le audiodescrizioni delle tracce video forniscono una narrazione degli elementi chiave visivi, senza interferire con l’audio o i dialoghi di un filmato. Gli elementi chiave visivi includono azioni, ambientazioni, linguaggio del corpo, grafica e testo visualizzato. Le audiodescrizioni sono usate principalmente da persone non vedenti che non possono seguire l’azione e le altre informazioni non acustiche presenti nel materiale video.

In altre parole, un’audiodescrizione è un po’ come la voce del narratore, comune in molti film e rappresentazioni teatrali. Lo scopo di questa voce narrante deve essere di descrivere tutto ciò che accade e che non può essere desunto direttamente dai dialoghi e dai suoni del filmato, come se lo si raccontasse alla radio, cioè a un ascoltatore, non a un telespettatore. È facile capire che la presenza di un’audiodescrizione può avere un’importanza cruciale per l’accessibilità, nel caso di filmati in cui il contesto non può essere ricavato direttamente dai dialoghi.

Alcuni esempi di audiodescrizioni sono contenuti nel nuovo sito Webmultimediale , nato a gennaio 2007 da un’idea di Roberto Ellero, esperto di accessibilità specializzatosi da alcuni anni nel settore della multimedialità per il Web.

Allo scopo di chiarire il concetto di audiodescrizione, riportiamo da Webmultimediale la trascrizione di un breve brano, tratto da un filmato che contiene la sintesi per il Web di un adattamento teatrale de Il Gabbiano Jonathan Livingston di Richard Bach.

[Voce narrante 1] È la storia di un gabbiano solitario a cui piaceva volare alto e di uno stormo ignorante a cui importava soltanto di mangiare.

[Voce narrante 2] Silenzio. Lo spazio è nella penombra. Fondali con gabbiani. Nel proscenio assi di legno adagiate su assi di ferro a mo’ di letto. Jonathan dorme sdraiato al centro su di un’asse. Ai lati la madre e la sorella che riordinano la scena, piegando stracci e lenzuola. Sulla sinistra, la madre di Jonathan, con un vestito bianco e sfrangiato, e il naso colorato di giallo; si rivolge brusca e sconfortata al figlio semi-dormiente che le sta accanto, e anche lui veste abiti simili.

MADRE: Sveglia! ... Jonathan svegliati!... allora: ti alzi o no?!... Eh sveglia!!! Ma possibile che non puoi essere come tutti gli altri?

Guardati: guardati! Sei tutto pelle ossa e sogni! Ma perché non lasci ai pellicani il volo radente e non ti dedichi a una dieta che sia più decente!? Sei tutto, tutto...

JONATHAN: ... tutto pelle ossa e sogni. Me lo hai già detto, mamma... come sempre. Quante volte ti devo dire che non mi importa per nulla di essere magro?

Come si può capire dal testo citato, Madre e Jonathan sono gli attori che dialogano nel filmato. Ciò che dicono e il modo in cui lo dicono è direttamente accessibile anche a un utente cieco, purché sia in grado di riprodurre il brano multimediale. Le due voci narranti aggiungono, invece, le informazioni che resterebbero altrimenti ignote a chi non è in grado di vedere cosa accade nel filmato: la prima voce legge, infatti, il contenuto di un cartello mostrato a video, la seconda voce descrive la scena, prima che la madre cominci a parlare.

Le due voci narranti sono dunque il contenuto dell’audiodescrizione, che deve essere aggiunta al brano multimediale che contiene già i dialoghi tra Jonathan e la madre.

Dal momento che un’audiodescrizione deve contestualizzare tutti i cambiamenti di scena e gli avvenimenti non desumibili dai dialoghi, è ovvio che deve essere sincronizzata con la traccia video. È importante, perciò, che la voce narrante s’inserisca nelle pause di silenzio dei dialoghi, in modo da non ostacolarne la comprensione.

Dal punto di vista tecnico, un’audiodescrizione è costituita da una o più tracce audio, che devono essere integrate con le tracce audio e video che costituiscono il contenuto del filmato o dell’animazione. Vedremo nel commento al punto di controllo 1.4 alcuni strumenti software con cui si può realizzare la sincronizzazione. L’aspetto tecnico è comunque secondario, in questo caso, rispetto all’aspetto autoriale. Le procedure per registrare un’audiodescrizione e sincronizzarla con un documento multimediale sono, infatti, relativamente semplici, benché possano risultare lunghe e noiose. Ciò che è invece molto meno semplice e scontato è cosa dire per descrivere una scena. Scrive a tal proposito Roberto Ellero su Webmultimediale:

Può sembrare strano, ma la cura dei contenuti audiovisivi richiede competenze e sensibilità umanistiche, è un lavoro di interpretazione e si lavora – all’origine – con il testo, prima ancora che con la videocamera, con il montaggio video, l’encoding e i formati.

Scrivere una buona audiodescrizione è, insomma, tutt’altro che banale. I modi per raccontare un evento, descrivere una scena, tratteggiare un personaggio possono essere diversissimi. Nei limiti del tempo concesso dalle pause dell’azione rappresentata nel video, la voce narrante deve cercare di descrivere il più obiettivamente possibile, con sintesi e precisione, l’ambientazione e i personaggi.

La qualità di un’audiodescrizione influenza, infatti, direttamente l’accessibilità di un documento audiovideo. Scrivere audiodescrizioni e sottotitolazioni di livello professionale richiede di rispettare una serie di regole e occorre un lungo tirocinio prima di raggiungere la sensibilità e la competenza necessarie.

Non sempre, però, è necessaria un’audiodescrizione. Spetta naturalmente agli autori valutare caso per caso se un determinato contributo multimediale può essere capito così com’è solo ascoltandone l’audio, oppure se è necessario inserire una voce narrante che dia informazioni contestuali. Le Tecniche di base per le WCAG 1.0 aggiungono a tal proposito una nota che dice:

Se non c’è alcuna informazione visuale importante, come per esempio nell’animazione di una testa parlante che descrive (tramite un discorso preregistrato) come usare il sito, allora non è necessaria un’audiodescrizione.

Ciò che conta, infatti, nell’esempio riportato dal documento delle Tecniche, è che l’ascoltatore recepisca le istruzioni sull’uso del sito, mentre non ha alcuna importanza informativa l’artificio grafico (la testa parlante animata), adoperato per veicolare le istruzioni.

Nel decidere quali contenuti commentare con un’audiodescrizione, è importante che gli autori facciano delle prove preliminari di ascolto senza guardare la traccia video: in tal modo potranno capire più facilmente se e quali elementi informativi mancano a un ascoltatore per comprendere chiaramente i contenuti. Meglio ancora sarebbe scrivere il copione di un’audiodescrizione dopo aver chiesto a qualcuno, che abbia ascoltato solo l’audio, di spiegare che cosa ha capito del filmato.

Nel caso di video in cui non è presente una traccia sonora o in cui manchi il parlato, potrebbe essere sufficiente una semplice descrizione testuale del contenuto, compatibilmente con gli scopi per cui il documento viene pubblicato sul Web (una voce narrante umana può comunicare, ovviamente, emozioni e sfumature che un testo scritto non è in grado di trasmettere, soprattutto se letto da una sintesi vocale).

Inizio pagina

Punto di controllo 1.4, priorità 1

Sottotitoli aperti e sottotitoli chiusi

Il punto di controllo 1.4 introduce due elementi essenziali per l’accessibilità dei contenuti multimediali: i sottotitoli e la sincronizzazione. Cominciamo dai sottotitoli.

Mentre le audiodescrizioni aiutano chi non può vedere, i sottotitoli servono a chi non può ascoltare i suoni e i dialoghi. Poiché tra i fruitori di contenuti multimediali possono esservi sia utenti privi di vista che utenti privi di udito, un brano audiovideo accessibile deve essere corredato sia di audiodescrizione sia di sottotitoli, meglio ancora se con la possibilità, per l’utente, di selezionare quale dei due tipi di ausilio preferisce utilizzare. Questo risultato può essere ottenuto sia integrando in un’unica presentazione multimediale audiodescrizione, sottotitoli e strumenti per selezionare l’una o gli altri, sia fornendo due diverse versioni del brano, una audiodescritta, l’altra sottotitolata.

I sottotitoli possono essere di due tipi, definiti rispettivamente, con terminologia inglese, open captions e closed captions. In italiano possiamo tradurre con “sottotitoli aperti” e “sottotitoli chiusi”, considerando caption come sinonimo di subtitle (“sottotitolo”). I sottotitoli aperti sono scritte che compaiono in sovraimpressione in qualche luogo dell’area occupata dal video. Sono parte integrante, cioè, della traccia video. Sono definiti “aperti” perché, laddove sono impostati, rimangono visibili senza che l’utente possa disattivarli (Figura 4.25 A). I sottotitoli chiusi, al contrario, sono scritte che compaiono in una regione differente da quella del video, di solito sotto (Figura 4.25 B). Non sono parte integrante della traccia o del segnale video, anzi per vederli occorre un apposito decodificatore hardware o software, e possono essere disattivati, cioè chiusi (da cui il nome) a discrezione dell’utente.

Posta la distinzione tra sottotitoli aperti e chiusi, viene naturale chiedersi: dal punto di vista dell’accessibilità, è meglio usare i primi o i secondi? In realtà non fa una gran differenza, se si eccettua il fatto che il testo dei sottotitoli chiusi, se opportunamente strutturato, può essere ingrandito a discrezione dell’utente, mentre quello dei sottotitoli aperti no, dal momento che è fuso con le immagini del filmato. Anche se – teoricamente – i sottotitoli chiusi potrebbero essere letti da una sintesi vocale, ciò non ha alcuna utilità pratica. I non vedenti, infatti, non hanno bisogno di sottotitoli, ma di audiodescrizioni: ascoltano direttamente i suoni e i dialoghi inseriti in un brano multimediale, per cui non ha importanza per loro se il testo dei sottotitoli fa tutt’uno con le immagini oppure è un oggetto esterno.

Tra i motivi che consigliano di preferire le sottotitolazioni chiuse ve ne sono almeno tre, ma non riguardano direttamente l’accessibilità dei contenuti per gli utenti con problemi di vista o d’udito. Essi sono:

• la possibilità di disattivare la sottotitolazione, per chi non ne ha bisogno;
• la possibilità di ricevere i sottotitoli nella propria lingua, nel caso di filmati dotati di closed captions multilingua;
• la ricercabilità dei termini usati nei sottotitoli, che, archiviati come comuni file di testo, possono essere indicizzati dai motori di ricerca.

Nessuno di questi vantaggi è però decisivo. Nessuno vieta infatti di predisporre più brani audiovideo del medesimo evento, di cui uno senza sottotitoli e uno o più con sottotitoli aperti, ciascuno in una lingua diversa. Il testo dei sottotitoli aperti può essere poi reso indicizzabile dai motori di ricerca allegando un file di trascrizione testuale.

Inizio pagina

Formati e player per il multimedia accessibile

L’invito che i punti di controllo 1.3 e 1.4 rivolgono ad autori e sviluppatori è ben chiaro: fornire contenuti multimediali sottotitolati e audiodescritti. Il modo di obbedire a tale invito richiede, invece, scelte molto meno semplici e chiare. Ciò non perché audiodescrivere e sottotitolare siano difficili dal punto di vista informatico: i software che consentono queste operazioni sono anzi piuttosto semplici da utilizzare e relativamente simili tra loro (non consideriamo per il momento la difficoltà autoriale di scrivere i testi).

Ciò che complica le cose è la quantità di formati e di riproduttori multimediali – o, più brevemente, player – esistenti: la scelta di un formato, qualunque esso sia, comporta vincoli ed esclusioni. Perciò, prima ancora di associare a un brano audiovideo dei sottotitoli chiusi e/o un’audiodescrizione, dobbiamo operare delle scelte preliminari, che devono essere fatte a ragion veduta, cercando il miglior compromesso tra i mezzi a disposizione (tempo, risorse hardware e software) e il fine di accessibilità che si intende raggiungere.

Il punto di partenza è certamente la scelta del formato. Chiunque abbia un minimo di esperienza nella fruizione o nella produzione di contenuti multimediali per il Web si sarà imbattuto prima o poi in uno dei seguenti tipi di file: AVI, WMV, ASF, MOV, QT, MPEG, MPG, MP4, RM, FLV, SWF. Molti dei brani audiovideo diffusi sul Web sono infatti codificati in uno dei formati associati ai precedenti tipi di file (che rappresentano comunque solo una parte dei tipi usati in area multimediale).

Tra i vincoli che la scelta di un formato comporta, il più importante è probabilmente quello del player che gli utenti dovranno usare per riprodurre i contenuti salvati in quel formato. Per esempio, pubblicare sul Web contenuti in formato WMV o AVI richiede che gli utenti abbiano installato Microsoft Windows Media Player . Analogamente, scegliere di pubblicare filmati in formato MOV o QT richiede che gli utenti dispongano di Apple QuickTime ; il formato RM richiede che sia installato RealPlayer ; i formati FLV e SWF richiedono la presenza di Adobe Flash Player .

Entro certi limiti i player di ultima generazione sono in grado di riprodurre anche formati non nativi, ma in linea generale c’è il serio rischio che un brano multimediale non possa essere riprodotto, se l’utente non dispone del player adatto. Ciò ha inevitabilmente una forte influenza sull’accessibilità: infatti, prima ancora di realizzare audiodescrizioni e sottotitoli, è indispensabile mettere gli utenti nella condizione di poter riprodurre un documento reso accessibile.

Produttori e distributori di contenuti multimediali non hanno, però, la possibilità di sapere in anticipo se e quale player un utente abbia installato sul proprio computer. Cosa si può fare, allora, per ridurre al minimo il rischio che gruppi più o meno numerosi di utenti restino tagliati fuori dalla fruizione dei contenuti pubblicati?

I metodi sono essenzialmente due, il primo dei quali è meno usato oggi che in passato, mentre il secondo è diventato recentemente di uso molto più comune:

• presentare uno stesso brano multimediale in più formati differenti;
• scegliere il formato che ha, dati alla mano, la maggiore penetrazione nel mercato.

Arcoiris.tv , noto sito d’informazione “televisiva” per il Web, offre un esempio del primo tipo di strategia: i suoi filmati sono offerti in vari formati, tra i quali quelli per Real Player e per Windows Media Player, e con differenti livelli di qualità, in modo da permettere la visione e lo scaricamento al maggior numero possibile di utenti, compresi quelli che hanno connessioni lente alla Rete.

Esempi del secondo tipo di strategia sono i grandi portali che aggregano comunità di utenti che condividono i loro video online. YouTube , Google Video , Yahoo! Video , MySpace , tanto per citare alcuni giganti del cosiddetto video sharing, hanno tutti scelto di trasformare i filmati caricati dagli utenti in un formato riproducibile con Adobe Flash Player, che si può considerare, per il momento, il vincitore di fatto nella guerra dei formati e dei player multimediali.

Perché hanno scelto Flash? Perché si tratta di un plug-in molto leggero in termini di peso e facile da installare, in grado di gestire ottimamente i flussi di dati audiovideo, dotato di un’interfaccia molto personalizzabile, e, soprattutto, presente ormai quasi su ogni computer. Viene distribuito attualmente insieme ai principali browser e sistemi operativi, il che libera in molti casi gli utenti dalla necessità di un’installazione separata.

Secondo i dati pubblicati a seguito di un sondaggio condotto da Millward Brown per conto di Adobe a dicembre 2006 (Figura 4.27), Adobe Flash Player risulta installato sul 98,3% dei computer in grado di navigare sul Web. L’unico player che può reggere il confronto come penetrazione nel mercato, secondo i dati del medesimo sondaggio, è Windows Media Player, che raggiunge l’83,2% dell’utenza. QuickTime di Apple e il player di Real Networks seguono molto staccati, con percentuali, rispettivamente, del 66,9% e del 55,3%. Ma non è questione solo di percentuali, quanto di composizione del pubblico raggiungibile. Mentre Windows Media Player deve la sua larga penetrazione quasi esclusivamente a un’utenza che usa sistemi operativi della serie Windows, Flash è invece utilizzato trasversalmente – sia pure in versioni non tutte allineate – sui più disparati sistemi operativi, tra cui Mac OS X, Linux, BeOS, Solaris, HP-UX, Poket PC. La versione più aggiornata di Flash , la 9.0, è disponibile sulle tre piattaforme principali, cioè Windows, Mac OS X e Linux. Oltre Flash, l’unico player disponibile anche per Linux, dei quattro citati, è RealPlayer, che ha però una penetrazione complessiva nettamente inferiore a quella di Flash.

Pubblicare, per esempio, contenuti audiovideo in formati riproducibili solo con QuickTime o Windows Media Player pone oggi un utente di sistemi Linux, che tentasse di installare gli appositi plug-in, di fronte a un messaggio simile a quelli mostrati in Figura 4.28.

Poiché l’accessibilità è una forma di protezione, non solo degli utenti con disabilità, ma anche di quelli che rappresentano minoranze tecnologiche, la scelta di un formato non compatibile con i sistemi operativi di nicchia dovrebbe, nei limiti del possibile, essere evitata. Ecco perché pubblicare in formati riproducibili con Flash è da ritenersi, al momento, la scelta migliore dal punto di vista della copertura dell’utenza e, cioè, dell’indipendenza dal dispositivo: tutti (o quasi) possono riprodurre lo stesso brano audiovideo, anche se usano sistemi operativi di nicchia.

Inizio pagina

Inserimento e sincronizzazione di sottotitoli chiusi

Esistono diversi programmi, la maggior parte dei quali a pagamento, che consentono di associare sottotitoli a brani audiovideo. Tra quelli gratuiti, è da segnalare Media Access Generator, più noto come MAGpie, un editor basato su Java, prodotto dal National Center for Accessible Media (NCAM) e giunto alla versione 2.0.2 per i sistemi Mac OS X e 2.0.3 per i sistemi Windows. Il programma è scaricabile da http://ncam.wgbh.org/webaccess/magpie/ .

La procedura di inserimento e sincronizzazione dei sottotitoli in MAGpie può valere come esempio del criterio da usare in tutti i programmi dello stesso tipo. Dall’uno all’altro cambiano l’aspetto grafico dell’area di lavoro, la disposizione e il nome dei comandi, le opzioni accessorie, ma i metodi da utilizzare restano più o meno gli stessi, e cioè:

• far scorrere avanti e indietro un brano audiovideo, a velocità normale, aumentata o ridotta, con lo scopo di identificare e marcare i punti di apparizione e scomparsa di ogni sottotitolo (punti che devono coincidere, all’incirca, con i momenti in cui i personaggi del filmato cominciano e finiscono le frasi da mettere in forma scritta);
• scrivere in un’apposita riga il testo di ciascun sottotitolo e il nome del parlante (o speaker);
• associare precisi valori temporali ai punti di apparizione e di scomparsa di ogni sottotitolo;
• esportare il prodotto finito in un file XML e/o di testo, contenente le informazioni necessarie affinché il brano multimediale sia riprodotto, con l’aggiunta dei sottotitoli sincronizzati, da un player compatibile.

Illustriamo ora brevemente le operazioni tipiche per creare un filmato sottotitolato con MAGpie, aiutandoci con alcune immagini catturate durante un lavoro di prova, per il quale abbiamo utilizzato un brano audiovideo in formato MOV, disponibile online all’indirizzo http://193.43.192.109/video.htm .

La prima operazione consiste nella scelta del filmato da sottotitolare: ciò può essere fatto tramite la finestra di dialogo mostrata in Figura 4.29.

Tra le impostazioni disponibili in questa finestra, sono da segnalare le opzioni di formattazione per il testo dei sottotitoli (Caption Styles) e per il testo che identifica il parlante (Speaker Styles). Per la nostra prova, abbiamo scelto un carattere Verdana grassetto da 14 punti, che garantisce una buona leggibilità. Per quanto riguarda i colori di primo piano e sfondo, è buona norma scegliere una combinazione ad alto contrasto (testo bianco su sfondo nero è l’impostazione predefinita).

Nell’area inferiore della maschera, chiamata Presentation layout, è possibile impostare le dimensioni in pixel del filmato sottotitolato e, soprattutto, le dimensioni dell’area dei sottotitoli (le voci Caption width e Caption height in Figura 4.29).

Il passo successivo è scegliere, mediante una nuova finestra di dialogo, se realizzare dei sottotitoli o un’audiodescrizione (Figura 4.30).

Eccoci dunque alla finestra di elaborazione principale (Figura 4.31). Da notare la pulsantiera con comandi analoghi a quelli di un videoregistratore, che serve per far andare avanti e indietro l’anteprima del filmato in corso di sottotitolazione (non visibile nell’immagine). I tre pulsanti a forma di triangolino servono per far avanzare il brano a velocità ridotta, normale o aumentata, così da rispondere a tutte le esigenze di ricerca all’interno del documento.

Nel blocco principale della finestra sono visibili le righe di sottotitolazione. I numeri nelle colonne Start Time e End Time contengono i tempi di comparsa e di scomparsa di ciascun sottotitolo, con precisione fino al centesimo di secondo. Appositi comandi del menu Captions, impartibili anche da tastiera, permettono di inserire in ciascuna delle due caselle il tempo corrispondente al punto in cui il brano è stato arrestato.

La colonna Speaker serve per inserire il nome del parlante, che di regola va indicato: la traccia video potrebbe non contenere, infatti, elementi sufficienti a consentire a un utente sordo o duro d’orecchi di capire chi sta pronunciando le parole di un sottotitolo.

La colonna Caption contiene, infine, le frasi pronunciate da ciascun parlante. Si noti che è importante indicare anche gli elementi sonori della scena che non fanno parte del parlato. In caso contrario, alcune frasi riportate nei sottotitoli potrebbero risultare non contestualizzate. Se alla riga 2, per esempio, non fosse riportato tra parentesi “i bambini ridono”, quel “No, no! Non cominciamo a ridere, eh!”, pronunciato alla riga 3 da Alberto Manzi, lascerebbe nell’aria la domanda: chi ha riso, e quando? È opportuno inoltre distinguere graficamente le note che riportano suoni e rumori d’ambiente dalle frasi pronunciate dai personaggi identificati come speaker: a tal fine, nell’esempio in Figura 4.31 questi incisi sono stati marcati con le parentesi e il corsivo.

Dopo aver finito l’inserimento del testo dei sottotitoli nell’apposita area della finestra di MAGpie, passiamo alla fase conclusiva del lavoro: l’esportazione di sottotitoli e dati di sincronizzazione, in un formato che possa essere riprodotto da un player multimediale. MAGpie offre quattro scelte (Figura 4.32): salvare i dati per QuickTime, per RealPlayer, per Windows Media Player e come testo semplice.

Poiché il brano originale era in formato MOV, che è un formato per QuickTime, l’esportazione che garantisce l’immediata riproducibilità del lavoro di sottotitolazione è quella identificata dall’etichetta QuickTime – SMIL 1.0 format. Scegliendo questa opzione, MAGpie genera due file: uno con estensione TXT e uno con estensione SMIL. Aprendo il secondo file con il player di QuickTime, parte la riproduzione del filmato, completo di sottotitoli. La Figura 4.33 mostra un fotogramma tratto dall’esecuzione del brano con QuickTime, a testimonianza del buon esito del lavoro di sottotitolazione svolto in MAGpie.

Inizio pagina

Informazioni di base sui formati di file per la sincronizzazione dei sottotitoli chiusi

Dobbiamo chiederci a questo punto cosa contengono i due file generati da MAGpie al termine della procedura di esportazione. Il file TXT è scritto con una sintassi specifica di QuickTime (formato QTtext) e contiene tre tipi d’informazioni:

• i dati stilistici che dicono al player QuickTime che carattere usare per i sottotitoli, che dimensione attribuirgli, quali sono i colori di primo piano e sfondo, qual è l’allineamento del testo;
• i valori temporali per la sincronizzazione dei sottotitoli con la traccia video;
• il testo dei sottotitoli.

Un estratto di questo file è riportato a titolo esemplificativo nel Listato 4.18.

È facile notare che la sintassi del formato QTtext prevede che le informazioni stilistiche siano racchiuse tra parentesi graffe e le informazioni temporali tra parentesi quadre. Nulla vieta, perciò, di realizzare manualmente un documento con simili caratteristiche, che possa essere “compreso” da QuickTime. Naturalmente, usare un editor come MAGpie, che automatizza l’applicazione delle regole sintattiche del formato, è sicuramente più comodo.

Il file con estensione SMIL è un file XML, scritto in SMIL (Synchronized Multimedia Integration Language) versione 1.0, un linguaggio standard del W3C per la marcatura di presentazioni multimediali. Contiene i comandi che dicono a QuickTime quali “pezzi” deve prendere e come deve assemblarli, dal punto di vista spaziale e temporale, per riprodurre il filmato sottotitolato.

Senza addentrarci in un discorso approfondito sulle caratteristiche di SMIL, notiamo che, scorrendo il Listato 4.19, che riporta il file SMIL esportato da MAGpie, troviamo un elemento LAYOUT, che contiene due elementi REGION. Il primo, identificato da id="videoregion", definisce altezza e larghezza in pixel dell’area occupata dalla traccia video; il secondo, identificato da id="textregion", definisce altezza e larghezza dell’area occupata dai sottotitoli.

Più sotto, nel corpo del documento, troviamo un elemento PAR, che contiene due elementi, VIDEO e TEXTSTREAM, che richiamano, tramite gli attributi region, i due valori videoregion e textregion. Lo scopo dei due elementi è riempire le aree generate dagli elementi REGION, visti in precedenza, con gli appositi contenuti, richiamati da attributi src: il file manzi7_s240x180.mov, che è il documento audiovideo originale, e il file manzi.it_IT.qt.txt, che contiene i sottotitoli e le indicazioni stilistiche e temporali. Gli attributi dur, infine, indicano a QuickTime la durata complessiva della traccia audiovideo e della traccia testuale con i sottotitoli.

Purtroppo le regole sintattiche valide per QuickTime non valgono per gli altri player. L’esportazione da MAGpie di un lavoro di sottotitolazione in formato RealPlayer produce, per esempio, due file un po’ diversi dai due visti per QuickTime. Invece di un file TXT viene generato un file, sempre di testo, ma con estensione RT. Tale file, così come l’analogo per QuickTime mostrato nel Listato 4.18, ha lo scopo di definire gli aspetti stilistici, temporali e testuali dei sottotitoli, ma lo fa in modo differente, come mostra l’estratto riportato nel Listato 4.20.

Il file SMIL per RealPlayer generato da MAGpie è invece molto simile a quello per QuickTime. Il cambiamento principale riguarda l’attributo xmlns, che non richiama lo spazio dei nomi xmlns:qt, a cui fa riferimento il file SMIL per QuickTime (si veda l’inizio del Listato 4.19). RealPlayer, infatti, non fa uso delle estensioni proprietarie gestite dal player di Apple.

Le differenze aumentano quando si passa a considerare ciò che serve per far riprodurre a Windows Media Player un brano sottotitolato. Il linguaggio di marcatura usato non è più SMIL, ma SAMI, acronimo di Synchronized Accessible Media Interchange, un linguaggio proprietario sviluppato da Microsoft, con scopi analoghi a SMIL (è possibile trovare informazioni dettagliate su http://msdn.microsoft.com/library ).

Esportando per Windows Media Player, MAGpie produce un unico file con estensione SMI. Questo file contiene (quasi) tutto il necessario, scritto appunto in SAMI: ovvero stili, tempistica e testi dei sottotitoli. Il “quasi” riguarda il fatto che manca il riferimento al brano che il file SMI sottotitola, ragion per cui i link che richiamano un video sottotitolato con SAMI devono contenere sia il riferimento al file multimediale sia il riferimento al file SMI. La forma tipica è href="file_audiovideo.wmv?SAMI=file_audiovideo.smi", in cui il file con i sottotitoli viene referenziato per mezzo di una stringa di query.

Il Listato 4.21 riporta un estratto dal file SMI generato da MAGpie, esportando per Windows Media Player la prova di sottotitolazione mostrata nel paragrafo precedente.

I file SAMI prodotti da MAGpie sono molto prolissi nella definizione degli stili. Chi ha conoscenza di CSS può agevolmente “asciugare” il contenuto del documento senza alterarne la resa, eliminando le definizioni di stile ripetitive a livello di paragrafo. Da notare anche che l’esportazione automatica di MAGpie definisce la dimensione dei caratteri in punti (pt), il che è sconsigliabile, se si vuole garantire agli utenti la possibilità di ingrandire i sottotitoli all’interno del browser. Meglio perciò sostituire i punti con un’unità di misura relativa.

Le cose cambiano ancora, se passiamo a video sottotitolati per Flash. In questo caso, la sottotitolazione può avvenire in due modi: o manualmente, creando all’interno dell’area di lavoro di Flash degli oggetti di testo contenenti i sottotitoli e sincronizzandoli poi con lo scorrimento della traccia video (si veda in proposito la guida di Tom Green ), oppure usando un componente esterno come Hi-Caption viewer . Questo componente permette di associare a un brano audiovideo un file XML di sottotitoli chiusi, con le necessarie informazioni di sincronizzazione. La prima soluzione è più laboriosa, la seconda è più rapida, anche se diviene realmente praticabile se si usa, per la generazione del file XML, il programma Hi-Caption Studio, che lavora in modo analogo a MAGpie (ma che non è gratuito come quello).

Il Listato 4.22 riporta un estratto da un file XML dimostrativo distribuito da HiSoftware.

Cambia ancora una volta la sintassi, ma le informazioni fornite da questo file XML sono le stesse già viste per gli altri tipi di file: stili dei sottotitoli, testo dei sottotitoli, tempistica della loro esecuzione (qui definita per mezzo dell’attributo start dell’elemento CC).

L’elemento nuovo che il codice nel Listato 4.22 introduce rispetto agli esempi precedenti è un meccanismo per definire la lingua dei sottotitoli. La coppia attributo/valore styleClass="ENUSCC", presente nell’elemento CAPTIONSET, definisce una serie di sottotitoli in lingua inglese. L’associazione è stabilita nell’elemento CCSTYLE con nome di stile "ENUSCC", per mezzo della coppia attributo/valore ccLang="en-US". Un’analoga associazione è stabilita per i sottotitoli in lingua spagnola, grazie a un altro elemento CCSTYLE, che ha stavolta nome di stile "escc-blanca" e attributo ccLang="es".

Il file XML del Listato 4.22, associato tramite il componente Hi-Caption viewer al brano audiovideo daVinci.wmv importato in Flash, permette di ottenere il filmato con sottotitoli chiusi dav02.swf, di cui in Figura 4.34 sono mostrati due fotogrammi, con i sottotitoli rispettivamente visibili e nascosti.

Lo scopo di questa veloce carrellata sui formati di file per i sottotitoli chiusi e la sincronizzazione non era quello di spiegare nel dettaglio le numerose caratteristiche sintattiche di ciascun formato: chi è interessato ad approfondire, troverà in Rete e in libreria specifiche e guide per ciascuno di essi. Gli scopi sono invece altri: da un lato, fornire informazioni di base per permettere al lettore di orientarsi tra le tante diversità che accompagnano la scelta di un formato multimediale e di un player (esempi: SAMI si usa con Windows Media Player, SMIL con QuickTime e RealPlayer; QuickTime vuole i sottotitoli in un file TXT, RealPlayer li vuole in un file RT; MAGpie non esporta per Flash, Hi-Caption Studio sì ecc.); dall’altro, mostrare quegli elementi comuni che, pur nel variare dei formati e degli editor, rimangono costanti, e cioè la necessità di codificare in un modo qualsiasi il nome del parlante, il testo e lo stile dei sottotitoli, la tempistica esatta per la loro sincronizzazione con la traccia video.

Inizio pagina

DFXP, la proposta del W3C per standardizzare i formati di sottotitolazione

Comprendere quali sono gli elementi comuni in ogni procedura di sottotitolazione è molto importante proprio per la varietà di formati esistenti: renderà infatti più semplice, una volta scelto un formato, servirsi in modo produttivo degli strumenti software adatti allo scopo.

È certo, però, che, anche avendo chiari gli elementi comuni, di fronte alla molteplicità di soluzioni esistenti per sottotitolare brani multimediali, lo sviluppatore deve affrontare un lavoro di apprendimento faticoso, che rimane soggetto, alla fine, a inevitabili problemi di compatibilità. In una situazione del genere, sarebbe utile poter disporre di una Raccomandazione W3C, in grado di fornire uno standard per la sottotitolazione.

In effetti il Consorzio non è stato a guardare e nel gennaio 2003 ha formato il Timed-Text Working Group, un gruppo di lavoro a cui è stato affidato il compito di produrre un linguaggio standard per l’interscambio di dati testuali temporizzati all’interno di presentazioni multimediali: quel che servirebbe, cioè, per consentire la riproduzione corretta di un brano sottotitolato, qualsiasi sia il player utilizzato dall’utente. Nella presentazione di questa attività sul sito W3C , si può leggere:

A oggi esiste una quantità di formati incompatibili per la sottotitolazione [captioning, subtitling] e per altre forme di testo temporizzato usate sul Web. Ciò significa che, quando si crea una presentazione SMIL, la porzione testuale spesso richiede di essere preparata per un solo particolare ambiente di riproduzione. Ciò pone la questione di come creare presentazioni SMIL interoperabili. Inoltre, la comunità che ruota intorno all’accessibilità fa forte affidamento sulla sottotitolazione per rendere i contenuti audiovisivi accessibili a un pubblico con disabilità uditive. La mancanza di un formato interoperabile aumenta in modo significativo il costo, già di per sé alto, di sottotitolare i contenuti web.

Il lavoro del gruppo Timed-Text ha prodotto finora due documenti, una nota e una specifica giunta allo stadio di candidate recommendation.

La nota, datata 27 aprile 2006, è intitolata Timed Text (TT) Authoring Format 1.0 Use Cases and Requirements. Il suo scopo è descritto proprio all’inizio:

Questo documento definisce scenari d’uso e requisiti per un formato autoriale di testo temporizzato. [...] Il testo temporizzato è un’informazione testuale che è internamente o esternamente associata con informazioni di temporizzazione.

La specifica candidata alla raccomandazione, datata 16 novembre 2006, è intitolata Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP) . Detto in breve, DFXP è il linguaggio di marcatura basato su XML che il W3C propone come formato universale per i sottotitoli da associare a brani audiovideo (e per ogni altro tipo di testo temporizzato):

DFXP fornisce una rappresentazione standardizzata di un sottoinsieme particolare di informazioni testuali, alle quali un autore o un sistema autoriale associano una semantica per gli stili, il layout e la temporizzazione, a scopo d’interscambio o di potenziale presentazione.

I listati 4.23, 4.24 e 4.25 riportano alcuni esempi di codice DFXP, tratti dal citato documento di specifiche del W3C.

Inizio pagina

Una soluzione semplice e altamente compatibile per realizzare
e distribuire video sottotitolati

I paragrafi precedenti possono aver gettato una luce un po’ sinistra sull’accessibilità dei contenuti audiovideo, lasciando presagire agli sviluppatori volenterosi l’obbligo di passare attraverso un piccolo girone infernale, fatto di formati, player e applicazioni più o meno incompatibili tra loro, prima di arrivare alla realizzazione e alla pubblicazione sul Web di un video sottotitolato.

Premesso che quell’incursione tra formati, player e relative differenze/incompatibilità era un dovere informativo di un libro sull’accessibilità, è lecito però chiedersi: esiste un modo semplice ed efficace per realizzare e pubblicare sul Web video dotati di sottotitoli chiusi? Fortunatamente esiste, e auspichiamo che possa diffondersi sempre più nel prossimo futuro.

Partiamo dal quarto formato di esportazione di MAGpie: l’opzione testo semplice (la voce "Plain Text..." della Figura 4.32). Questo tipo di esportazione prevede a sua volta tre opzioni, visibili in Figura 4.36.

Selezionando solo la terza opzione (Export comment entries), si ottiene una trascrizione testuale dei sottotitoli. Il risultato è simile al copione di una sceneggiatura teatrale. Questo file di trascrizione può essere messo a disposizione degli utenti come alternativa a un brano multimediale, a vantaggio di chi non ha la possibilità di riprodurlo (per esempio perché non dispone del player adatto o perché ha un computer obsoleto).

La selezione delle opzioni Export start timecodes e Export end timecodes consente, invece, di creare un file di testo in cui i singoli sottotitoli sono preceduti dai dati temporali per la sincronizzazione, come nel Listato 4.26.

Un file di testo simile a questo può essere utilizzato per associare dei sottotitoli chiusi a un filmato caricato sui server di un sito di video in condivisione. Google Video è per ora l’unico operatore, in questo settore sempre più importante del Web, che offra la possibilità nativa di associare sottotitoli chiusi ai video caricati dagli utenti. Ciò può essere fatto sia caricando un file di testo in formato UTF-8 sia incollando direttamente il testo dei sottotitoli all’interno della finestra “Aggiungi/Modifica”, mostrata in Figura 4.37, avendo cura di far precedere il testo di ogni sottotitolo dal solo codice temporale che ne indica la comparsa a schermo.

Il risultato di questa operazione, tecnicamente elementare, è mostrato in Figura 4.38.

Caricando e sottotitolando un filmato in Google Video (o in qualunque altro sistema di videocondivisione dotato di analoghe caratteristiche) otteniamo almeno tre vantaggi per l’accessibilità:

1. la conversione automatica del video in formato Flash, che garantisce attualmente la maggiore compatibilità con browser e sistemi operativi;
2. un metodo semplice, diretto ed economico per associare sottotitoli a un video;
3. la possibilità di incorporare il filmato in pagine web collocate su altri siti, scaricando sul fornitore (in questo caso Google) gli oneri dello spazio di archiviazione del documento e del consumo di banda.

Il codice di marcatura che Google Video suggerisce di usare per incorporare un brano audiovideo su altri siti è in verità poco rispettoso degli standard W3C, perché basato sull’uso dell’elemento proprietario EMBED (Listato 4.27).

Ne proponiamo di seguito una versione modificata (Listato 4.28), che fa ricorso al sostituto standard di EMBED, l’elemento OBJECT, e all’uso di un commento condizionale (<!--[if IE]> ... <![endif]-->), che serve per fornire al solo Internet Explorer per Windows un codice leggermente diverso, adatto a compensare una delle tante “eccentricità” di questo browser.

Si noti la presenza, nel codice precedente, di un testo alternativo all’interno dell’elemento OBJECT, destinato a chi usa un browser non in grado di riprodurre i contenuti Flash. La Figura 4.39 mostra il testo alternativo, visualizzato nel browser testuale Lynx al posto del filmato.

La Figura 4.40. mostra, infine, il risultato dell’incorporamento del video sottotitolato in una pagina web residente altrove, ottenuto usando il codice nel Listato 4.28.

I sottotitoli chiusi, in un filmato incorporato, appaiono in sovrimpressione al video (Figura 4.40) invece che in un’area sottostante. Ciò può peggiorare la loro leggibilità, in ragione del tipo di sfondo su cui si trovano sovrapposti e della piccolezza dei caratteri. Si può ovviare parzialmente al problema, ingrandendo la finestra del filmato, anche se a scapito della qualità delle immagini: verranno così ingranditi proporzionalmente anche i caratteri dei sottotitoli. Per ingrandire la finestra del filmato, occorre impostare per gli attributi height e width dell’elemento OBJECT valori più elevati di quelli forniti da Google Video per l’elemento EMBED.

Inizio pagina

Competenze e strumenti per scrivere sottotitoli per il Web

Al lettore attento non sarà sfuggito che questo lungo commento al punto di controllo 1.4 ha trattato finora soltanto gli aspetti tecnico-informatici della sottotitolazione. In realtà scrivere sottotitoli corretti ed efficaci è la parte principale e più difficile del lavoro.

Perché allora dedichiamo al tema della scrittura dei sottotitoli solo un paragrafo rispetto al tanto spazio concesso alle questioni tecniche? Semplicemente perché la sottotitolazione per il Web è qualcosa di nuovo e diverso rispetto alla sottotitolazione per i programmi televisivi, per i film o, in tempi più recenti, per i DVD. Mentre per la sottotitolazione tradizionale esiste un’ampia letteratura, derivante da decenni di esperienza, per il Web captioning non esistono ancora linee guida autoriali né certificazioni professionali ufficiali né percorsi di formazione standardizzati. La quantità di video sottotitolati disponibili online è ancora modesta, anche se in crescita, e la maggior parte è realizzata da autori improvvisati o comunque non specializzati nella scrittura di sottotitoli.

Ciò premesso, le linee guida che saranno scritte un domani per raccomandare agli autori come scrivere per il Web sottotitoli professionali, o almeno decenti, dovranno tener conto delle caratteristiche particolari di questo mezzo, che non possono non influenzare anche i contenuti testuali. Per esempio:

• la leggibilità dei testi e delle immagini è relativamente scarsa;
• l’attenzione degli utenti al brano multimediale e ai sottotitoli è di solito contesa da altri programmi e contenuti visibili sulla scrivania virtuale del computer.

L’esperto americano Gary Robson, autore di libri sulla scrittura di sottotitoli e di una guida online intitolata Closed Captioning Faq , risponde nel modo seguente alla domanda su quali siano le competenze necessarie per scrivere sottotitoli offline (cioè preregistrati, non in tempo reale).

Requisiti principali sono il lessico e la competenza linguistica. Chi scrive sottotitoli offline avrà a che fare con un’ampia varietà di terminologie in molte differenti situazioni. Queste spaziano dal gergo popolare al gergo tecnico ai dialetti locali: molto di tutto ciò non si trova nei libri di consultazione. Una laurea in inglese (o nella lingua primaria nella quale starete sottotitolando) o una laurea in lingue sono di grande aiuto.

C’è inoltre una qualità difficile da definire in un buon autore di sottotitoli offline, che si manifesta nel modo in cui le frasi sono suddivise tra i sottotitoli, nel modo in cui i sottotitoli sono posizionati e formattati, e nella regolarità della sincronizzazione.

Il canadese Joe Clark, dal canto suo, pone l’accento sulla necessità di un’immersione completa nel mondo dei testi sottotitolati, perché si apprende anche e soprattutto osservando, studiando la materia sul campo, piuttosto che mandando a memoria qualche frettolosa regoletta. Ecco cosa scrive Clark nel tredicesimo capitolo, dedicato alla multimedialità, del suo Building Accessible Websites ).

Suggerirei, a chiunque speri di compiere, sovrintendere, gestire, delegare o semplicemente comprendere una qualsiasi forma di sottotitolazione o di audiodescrizione, di spendere un paio di settimane non facendo nient’altro che osservare sottotitolazioni e audiodescrizioni.

Chi si occupa di scrivere i sottotitoli per il Web, qualunque sia la sua formazione, dovrà comunque confrontarsi con la trascrizione del video da sottotitolare. Questa è infatti la prima e ineliminabile fase del lavoro. La trascrizione può essere resa più comoda usando ausili come:

• un comando a pedale (per esempio Vpedal , che, connesso a un computer tramite una porta seriale, USB o giochi, è in grado di comandare svariati software per la riproduzione di contenuti multimediali; sarà possibile in tal modo riascoltare tutte le volte che serve uno stesso frammento di parlato, fino a che non si è sufficientemente sicuri delle frasi da trascrivere, avendo al contempo le mani libere per altre operazioni;
• un programma di riconoscimento vocale (per esempio IBM Via Voice , o iListen per Mac OS X), al quale il sottotitolatore ripete le frasi appena ascoltate, in modo che il software le trasformi in testo scritto; se opportunamente addestrati, questi programmi sono in grado di riconoscere fino al 95% delle parole pronunciate, riducendo così notevolmente il carico di lavoro dell’addetto alla trascrizione.

Una volta terminata quest’operazione, il file di testo ottenuto potrà essere importato in programmi come MAGpie o Hi-Caption e successivamente spezzato nei frammenti necessari a comporre i singoli sottotitoli.

Sottotitolare in tempo reale

L’evoluzione delle tecnologie per il Web rende possibile anche una sottotitolazione in tempo reale, adatta a eventi dal vivo come videoconferenze, seminari, lezioni a distanza, incontri sportivi, processi ecc., trasmessi in streaming.

Esistono specifici programmi, come il CPC-800 Realtime Webcast Captioning Software , che consentono di fondere in un unico flusso le immagini catturate da una telecamera e il testo dei sottotitoli generato attraverso un software collegato. Il flusso unificato viene poi inviato, come un normale video sottotitolato, ai browser web degli utenti collegati per assistere in diretta all’evento.

Esiste un piccolo sfasamento tra l’audio e i relativi sottotitoli (la società americana CPC garantisce che non supera i due secondi), dovuto al fatto che i sottotitoli non sono generati magicamente, ma sono il risultato di un intervento complesso di “traduzione” del parlato in testo scritto, che si svolge appunto in tempo reale.

Sono due i sistemi, alternativi l’uno all’altro, utilizzati per generare al volo la sottotitolazione: la scrittura stenografica e il riconoscimento vocale.

Il metodo stenografico richiede la presenza di uno stenografo sottotitolatore professionista, che deve tradurre in testo scritto non solo i dialoghi, ma anche i suoni d’ambiente. Si tratta di un lavoro non facile, che richiede da un lato competenze linguistiche non comuni, dall’altro una resistenza fisica altrettanto non comune: in situazioni d’emergenza, infatti, come eventi dal vivo importanti e di lunga durata, può essere necessario rimanere a sottotitolare per ore di seguito, senza alcuna interruzione. Se lo stenografo perde la concentrazione e la lucidità, l’effetto sui sottotitoli sarà tra il comico e il grottesco.

Lo strumento usato per stenografare è un particolare tipo di macchina per scrivere, che è in grado d’interfacciarsi con un computer e con appositi software, che aiutano lo stenografo fornendogli dizionari e suggerimenti per completare le parole e le frasi che ha cominciato a scrivere. L’output viene inviato in tempo reale al software adibito a fondere in un unico flusso i dati provenienti dalla telecamera con il testo dei sottotitoli.

L’altro metodo utilizzato per generare al volo i sottotitoli è quello del riconoscimento vocale. Un addetto, il cosiddetto shadow speaker (“oratore ombra”), dotato di cuffia e microfono in grado di sopprimere i rumori d’ambiente, ripete ad alta voce, parola per parola, i dialoghi dell’evento da sottotitolare. Un programma di riconoscimento vocale, del tipo di Dragon Naturally Speaking o IBM Via voice, già opportunamente addestrato, converte le parole pronunciate dallo speaker in testo scritto e invia il suo output al solito software di raccordo, che lo fonde con i dati audiovideo provenienti dalla telecamera.

Le trascrizioni testuali

Audiodescrizioni e sottotitoli non sono in grado di risolvere tutti i problemi di accessibilità legati alla pubblicazione di contenuti multimediali. Per usufruire delle prime occorre non avere problemi d’udito, per usufruire dei secondi occorre riuscire a leggerne il testo con la vista. Per entrambi, serve avere un computer e programmi in grado di riprodurre i contenuti multimediali.

Come permettere a un utente sordocieco o a uno privo di attrezzature multimediali di accedere ai contenuti di un brano audiovideo? Lo strumento adatto a questo scopo è la trascrizione testuale.

Un utente capace di leggere il Braille e uno dotato di computer o programmi obsoleti potranno servirsi entrambi della trascrizione testuale. Questa dovrà contenere sia gli elementi di un’audiodescrizione sia il testo dei sottotitoli, cioè la somma di ambientazione e parlato. A chi non può né vedere né sentire devono essere forniti, infatti, sia gli elementi visivi della scena sia quelli uditivi (dialoghi, suoni, rumori d’ambiente).

Esempi di trascrizioni testuali in italiano sono disponibili su Webmultimediale (per esempio: http://www.webmultimediale.org/gabbiano1_trascrizione.txt ).

Una trascrizione testuale non può e non dovrebbe essere usata per sostituire audiodescrizioni e sottotitoli. La lettura di una trascrizione, infatti, per quanto ben scritto e preciso possa esserne il testo, è cosa ben diversa dall’ascoltare e/o dal vedere direttamente un brano multimediale. Va considerata, invece, come il terzo elemento nella catena dell’accessibilità, che parte con la pubblicazione sul Web di contenuti multimediali.

In conclusione, un brano audiovideo, tolti alcuni casi particolari, può essere considerato veramente accessibile solo se è corredato da tutti e tre gli elementi che abbiamo analizzato nel commento al punto di controllo 1.4, cioè:

1. audiodescrizione;
2. sottotitoli;
3. trascrizione testuale.

Inizio pagina

Punto di controllo 1.5, priorità 3

Collegamenti testuali ridondanti per mappe immagine lato client

L’esempio che le Tecniche HTML per le WCAG 1.0 forniscono per l’applicazione di questo punto di controllo è basato sull’uso dell’elemento OBJECT (http://www.w3.org/TR/WCAG10-HTML-TECHS/#client-side-redundant-text ). Il codice HTML è mostrato nel Listato 4.29.

Il codice è strutturato in modo da consentire l’accesso ai collegamenti anche in modalità solo testo. Se il browser, infatti, non è in grado di visualizzare l’immagine usata come mappa, richiamata dall’attributo data di OBJECT, viene caricato il contenuto interno all’elemento, che è appunto la serie dei link testuali inserita nell’elemento MAP. Di seguito è illustrato il funzionamento del meccanismo: in Figura 4.42 A è mostrata la mappa immagine caricata in un browser grafico, in Figura 4.42 B la visualizzazione alternativa che si ottiene con il browser testuale Lynx.

La soluzione proposta dalle Tecniche WCAG non tiene conto in realtà dei problemi di ipovedenti e disabili motori. I collegamenti testuali messi all’interno di OBJECT non sono infatti disponibili sempre, ma solo se si naviga in modalità solo testo: non sono perciò veramente ridondanti, ma piuttosto alternativi. Poiché capita spesso che le mappe immagine siano oggettini grafici al cui interno sono disegnate aree sensibili microscopiche, ecco, allora, che sarebbe molto utile disporre di collegamenti testuali ridondanti insieme con la mappa immagine, non come alternativa. Un ipovedente o un disabile motorio possono trovare, infatti, difficoltà notevoli – e soprattutto evitabili – nell’identificare e attivare una regione sensibile all’interno di una mappa, se quella regione è troppo piccola o se i suoi contorni sono troppo irregolari e vicini ad altre zone sensibili.

Problemi di questo tipo si verificano soprattutto con mappe immagine che rappresentano cartine geografiche. Suggeriamo perciò, quando si creano mappe con aree sensibili di pochi pixel e/o dai contorni frastagliati, di ripetere sempre in forma testuale, nella parte visibile del documento, accanto alla mappa, l’elenco dei collegamenti che essa contiene.

Consideriamo, a titolo di esempio, una piccola mappa immagine lato client che mostra le regioni italiane (Listato 4.30). L’oggetto grafico che contiene la cartina dell’Italia è alto poco più di 150 pixel e largo meno di 200.

Tra i possibili modi di affiancare alla cartina una serie di link testuali ridondanti, uno dei più intuitivi consiste nel creare un elenco puntato, contenente gli stessi collegamenti della mappa, come nel Listato 4.31.

Un’altra soluzione, più compatta graficamente, consiste nel porre i collegamenti ridondanti all’interno di un menu SELECT (Listato 4.32).

Di seguito sono mostrate due possibili applicazioni delle soluzioni proposte:

• in Figura 4.43 A un elenco di collegamenti testuali, sul modello del Listato 4.31;
• in Figura 4.43 B, un menu di tipo SELECT.

In entrambi i casi, un utente ipovedente o con difficoltà motorie ha almeno due vantaggi, rispetto a una pagina in cui sia presente solo la mappa:

• può ingrandire il testo dei collegamenti testuali;
• può effettuare le scelte da tastiera, avendo un riscontro immediato circa la regione attualmente selezionata (o per via di effetti di attivazione sui link dell’elenco o perché il nome della regione compare nella casella visibile del menu SELECT).