Chiarire l’uso della lingua

Punto di controllo 4.1, priorità 1

La complessa questione dei cambi di lingua

Il punto di controllo 4.1 è tra i più problematici da applicare nelle WCAG 1.0. Da rimedio utile per l’accessibilità, la segnalazione dei cambi di lingua può facilmente trasformarsi, in certi casi, in una soluzione peggiore del male che intende curare. Per capire il senso della precedente affermazione, occorre però procedere per gradi, perché i cambi di lingua sono un argomento complesso, in cui gli aspetti che riguardano l’informatica e il software (per esempio il funzionamento degli screen reader) sono indissolubilmente connessi ad aspetti linguistici, che pure occorre conoscere, se si vuole rispettare il punto di controllo 4.1 in un modo che sia veramente accessibile.

Prima di entrare nel vivo dell’argomento, è utile tuttavia una precisazione: decidere dove cambia la lingua in un testo non può essere compito degli sviluppatori, cioè dei tecnici del Web. È una questione che riguarda i contenuti, e dunque gli autori. In un testo a stampa, gli autori (o i revisori di bozze) segnalano convenzionalmente con il corsivo la presenza di una parola o di una frase straniera. Qualcosa di analogo, non l’uso del corsivo, ma la segnalazione, dovrebbe avvenire per i testi pubblicati sul Web, dove è auspicabile che nasca una sinergia tra autori e sviluppatori: ai primi il compito di segnalare i contenuti scritti in una lingua diversa da quella principale del documento, ai secondi il compito di tradurre le segnalazioni in interventi sul codice di marcatura, con l’inserimento degli attributi lang e/o xml:lang opportunamente valorizzati.

Ciò premesso, cominciamo partendo dall’unico esempio di cambio di lingua proposto dal documento di tecniche HTML associato alle WCAG 1.0 :

Perché, dunque, occorre segnalare i cambi di lingua? Lo spiega il brano che correda il frammento di codice qui riportato.

Identificare i cambi di lingua è importante per una serie di ragioni:

• gli utenti che leggono i documenti in braille potranno sostituire i codici di controllo appropriati nel punto in cui incontrano un cambio di lingua, così da garantire che il software di traduzione braille possa generare i caratteri corretti (le lettere accentate, per esempio). Questi codici di controllo impediscono anche la generazione delle contrazioni braille, che potrebbero confondere ulteriormente l’utente. Le contrazioni braille combinano gruppi ripetitivi di caratteri, che appaiono usualmente in celle multiple, in una singola cella. Per esempio, “ing” che prende di solito tre celle (una per ogni carattere) può essere contratto in una sola cella.
• In modo simile, i sintetizzatori vocali che “parlano” più lingue saranno in grado di generare il testo con l’accento e la pronuncia appropriati. Se i cambi non sono marcati, il sintetizzatore farà del suo meglio per pronunciare le parole nella lingua primaria per la quale è impostato. Così, la parola francese per automobile, “voiture”, sarà pronunciata “voter” da un sintetizzatore vocale che usi l’inglese come lingua primaria.
• Gli utenti che non sono in grado di tradurre direttamente da una lingua a un’altra, potranno avvalersi di traduzioni automatiche per le lingue che non conoscono.

Inizio pagina

I nomi propri stranieri richiedono un cambio di lingua?

Fin qui sembra tutto perfettamente logico e coerente, ma... C’è un “ma”, infatti: non esiste, né nelle WCAG 1.0 né nei documenti tecnici associati, una qualsivoglia definizione di “cambio di lingua”. Ciò crea non poca confusione, soprattutto in considerazione delle spiegazioni sopra riportate, che associano la segnalazione dei cambi di lingua alla possibilità di ottenere dai sintetizzatori vocali una pronuncia corretta dei termini considerati stranieri rispetto alla lingua primaria impostata. Così, gli sviluppatori italiani che desiderano applicare il punto di controllo 4.1 si trovano di fronte a continui dubbi, non sapendo se marcare oppure no come cambi di lingua una gran quantità di parole con pronuncia diversa da quella italiana classica, che è facile trovare inserite in testi scritti nella nostra lingua.

Prendiamo il caso dei nomi propri stranieri: sono da marcare come cambi di lingua? Per scoprirlo, cominciamo col considerare questo breve testo, tratto da un sito web:

Nel Novembre 2005 sono gli unici artisti italiani a suonare al Memorial Rabin a Tel Aviv alla presenza di Bill e Hillary Clinton, di Sharon e di Shimon Perez.

Compaiono in questo testo (che, detto per inciso, parla di un gruppo musicale chiamato Solis String Quartet) numerosi nomi propri che non hanno l’aspetto di nomi italiani: “Memorial Rabin”, “Tel Aviv”, “Bill”, “Hillary Clinton”, “Sharon”, “Shimon Perez”. Alcuni rimarrebbero comprensibili per un ascoltatore anche se letti da una sintesi vocale seguendo le regole fonetiche dell’italiano (“Bill”, “Memorial Rabin”). Ma altri rischiano di essere fraintesi. Senza un cambio di lingua, “Hillary” potrebbe essere letto “Illàri”, “Sharon” sarebbe italianizzato in “Sàron” e “Shimon” in “Sìmon”.

La domanda è: se questi sono cambi di lingua, che lingua bisogna segnalare nel codice di marcatura? Per “Hillary Clinton” sarebbe facile rispondere che la lingua da segnalare è l’inglese (per esempio: <span lang="en">Hillary Clinton</span>). Ma per “Sharon” e “Shimon Perez”? Ammesso che lo sviluppatore sappia, e non è scontato che lo sappia, che i due nomi sono quelli di due importanti uomini politici israeliani, sorge una nuova domanda: sono scritti forse in ebraico, la lingua parlata in Israele? La risposta è, evidentemente, no. L’ebraico si scrive da destra verso sinistra e, soprattutto, con un alfabeto diverso dal nostro. Sono piuttosto traslitterazioni convenzionali in caratteri latini dei nomi ebraici dei due politici. Come marcarle, allora? In nessun modo, perché non esiste un criterio per segnalare nel codice, in HTML e XHTML, come dovrebbero essere pronunciati da un sintetizzatore vocale dei nomi traslitterati da una lingua che si scrive con un differente alfabeto.

Ma sono i nomi propri in generale, non solo quelli traslitterati, che, a volerli considerare cambi di lingua, causano problemi. Consideriamo per esempio un paragrafo tratto dai ringraziamenti presenti nella traduzione italiana delle specifiche CSS2:

Ha contribuito un certo numero di esperti invitati nel Gruppo di lavoro: George Kersher, Glenn Rippel (Bitstream), Jeff Veen (HotWired), Markku T. Hakkinen (The Productivity Works), Martin Dürst (W3C, in precedenza Universität Zürich), Roy Platon (RAL), Todd Fahrner (Verso), Tim Boland (NIST), Eric Meyer (Case Western Reserve University) e Vincent Quint (W3C).

Se volessimo assicurare a ogni nome proprio citato nel brano la pronuncia corretta da parte di un sintetizzatore multilingua, dovremmo prima identificare la lingua in cui ogni nome va pronunciato (Jeff Veen sarà olandese o fiammingo? Glenn Rippel americano o tedesco? Vincent Quint inglese o francese?). Sviluppatori e autori dovrebbero essere enciclopedisti poliglotti, per identificare correttamente i cambi di lingua da attribuire ai nomi di un team internazionale, oppure dovrebbero conoscere direttamente ogni persona, città, località nominata in un testo... Per non parlare della perdita di tempo.

La verità è che non vale la pena di impazzire per questo. Le WCAG 1.0 non lo dicono, ma i nomi propri, con buona pace di quelli che pensano il contrario, non dovrebbero essere marcati come cambi di lingua, anche se la loro pronuncia non corrisponde a quella italiana classica (o alla pronuncia classica di qualsiasi altra lingua impostata come primaria in un programma di sintesi vocale).

In ogni caso, gli attributi lang e xml:lang di HTML e XHTML non sono gli strumenti adatti per gestire le pronunce dei nomi propri: le Specifiche SSML e PLS del W3C offrono, invece, tutti gli strumenti per fornire l’esatta pronuncia dei nomi stranieri, senza coinvolgere il concetto di cambio di lingua (si vedano i box di approfondimento su questi due documenti, più avanti in questo stesso capitolo).

Inizio pagina

Cos’è un cambio di lingua?

Ci avviciniamo allora al concetto principale. Cos’è in definitiva un cambio di lingua?

Facile rispondere che è il passaggio da una lingua a un’altra. Ma come facciamo a identificare questo passaggio? Le WCAG 1.0 non lo spiegano, ma l’esempio riportato nel Listato 7.1, tratto dal documento di tecniche HTML, è significativo: c’è un discorso di senso compiuto in inglese che contiene al suo interno due frammenti anch’essi di senso compiuto, uno in francese (“je ne sais quoi”) e l’altro in italiano (“Piacere”).

In accordo con l’esempio riportato dalle WCAG, proponiamo di considerare, e marcare, come cambi di lingua solo i frammenti di senso compiuto, appartenenti a una lingua diversa da quella principale usata in un documento (la regola ammette poche eccezioni, che esamineremo nel paragrafo successivo).

Per frammenti di senso compiuto intendiamo qualsiasi brano costituito almeno da una frase, anche brevissima, che appartenga inequivocabilmente a una data lingua.

Limitare i cambi di lingua ai soli frammenti di senso compiuto permette di risolvere parecchi problemi. Uno di questi è l’identificazione sicura della lingua da segnalare nel codice di marcatura. All’interno di una frase le parole si chiariscono a vicenda; hanno e creano un contesto: diventa così possibile eliminare l’ambiguità che deriva dal fatto che la stessa grafia può indicare, in lingue diverse, parole differenti. La frase “The car is red” è inequivocabilmente inglese, ma la parola “car” da sola potrebbe essere tanto inglese, nel significato di “automobile”, quanto francese, nel significato di “poiché”. La frase “C’erano file di semafori rossi” è inequivocabilmente italiana, ma “file” da solo potrebbe essere tanto italiano quanto inglese (in inglese vuol dire “archivio, documento”).

Marcare come cambi di lingua solo le frasi straniere di senso compiuto ci permette inoltre di evitare dubbi e segnalazioni di cambio di lingua troppo numerose e forse errate. Soprattutto in certi ambiti tecnici e commerciali, è infatti una diffusa abitudine quella di riempire i testi italiani di parole straniere, usate come prestiti linguistici non adattati alle forme della nostra lingua.

Per capire meglio il problema, consideriamo il brano seguente, tratto da un documento tecnico reperibile sul Web (è una presentazione sulla gestione del colore nella stampa):

1. creare il profilo ICC di una macchina offset (6 slide);
2. uso del profilo ICC: quadricromia e proofing (4 slide);
3. workflow dello stampatore: strategia e tattica (23 slide).

Ci sono quattro parole che non hanno la forma classica di parole italiane: sono “offset”, “slide”, “proofing” e “workflow”. Vengono tutte e quattro dall’inglese, ma in ambito tecnico sono usate di frequente anche in italiano (“offset”, a differenza delle altre tre, è presente anche nel Vocabolario italiano Treccani). Dovendo comporre una pagina HTML contenente i tre punti dell’esempio citato, se non limitassimo la segnalazione dei cambi di lingua ai soli frammenti di senso compiuto (che qui non ci sono), ci troveremmo nel dubbio se inserire nel codice di marcatura cinque o addirittura sei cambi di lingua: cinque, se non volessimo considerare straniera la parola “offset”, riportata nel vocabolario d’italiano; sei, se volessimo dare più importanza al fattore della comune origine inglese dei quattro termini (tre cambi di lingua per “slide”, che ricorre tre volte, più un cambio ciascuno per “offset”, “proofing” e “workflow”).

È facile rendersi conto che un simile modo di concepire i cambi di lingua è inapplicabile nella pratica.

Gli sviluppatori dovrebbero dotarsi di vocabolari e di pazienza infinita, e poi cominciare a spulciare tutti i testi da mettere on line, alla ricerca delle parole che non si pronunciano come nell’italiano classico o che non compaiono nei dizionari e nei vocabolari di italiano. Tutti i prestiti linguistici, anche quelli di vecchia data, rischierebbero di entrare nel mirino: ogni occorrenza di “mouse”, “computer”, “penalty”, “teenager”, “night” (inteso come locale notturno), “web”, “coupé”, “abat-jour”, “champagne”, “apartheid” ecc., per un totale di migliaia e migliaia di parole, sarebbe passibile di essere marcata come cambio di lingua, se ci si limitasse a considerare la diversa pronuncia, rispetto all’italiano classico, di una singola parola all’interno di una frase. Portare a termine un’opera del genere, anche per un sito di piccole dimensioni, rischierebbe di diventare per gli sviluppatori un compito improbo, faticosissimo. Ma sarebbe soprattutto un compito inutile, anzi dannoso per l’accessibilità (e qui ci ricolleghiamo, finalmente, all’affermazione che apre il nostro approfondimento sui cambi di lingua).

Perché dannoso? Innanzitutto perché gli screen reader capaci di cambiare al volo il motore di sintesi, come sono in grado di fare le versioni più recenti di Jaws, nel cambiare lingua di solito cambiano anche voce. In tal caso, se due o più lingue si alternano all’interno della stessa frase, l’effetto sulla comprensione del testo da parte dell’ascoltatore può essere catastrofico: non si ha più, infatti, l’impressione di ascoltare un testo unitario, ma un susseguirsi disarticolato di voci diverse, con l’aggravante che le parole straniere, se sono pronunciate secondo le regole fonetiche di una lingua che non è l’italiano, possono risultare poco o nulla comprensibili a un orecchio abituato alla pronuncia italianizzata dei termini stranieri.

Nell’infarcire di cambi di lingua una singola frase, l’ascoltatore rischia di perdere il senso del discorso, a causa di un normale fattore psicologico: la comprensione non nasce, infatti, dall’ascoltare un miscuglio di voci che dicono singole parole staccate l’una dall’altra, ma dall’ascoltare frasi composte da un flusso unitario di parole concatenate.

La separazione tra le parole esiste infatti solo nella scrittura: nel parlato, esse sono attaccate l’una all’altra, ed è la loro concatenazione, il loro “fondersi” in un flusso continuo, che rende “naturali” e comprensibili le frasi che ascoltiamo da qualcuno che parla nella nostra lingua.

Consideriamo per esempio questa frase:

Ho collegato il mouse al computer.

Detta da un italiano, può essere compresa da qualsiasi altro italiano che abbia una minima conoscenza di informatica. Ma, in una simile frase, tutte le parole, anche quelle di origine inglese, sono di solito pronunciate da un’unica voce e sono attaccate l’una all’altra; la pronuncia di “mouse” e “computer” viene inoltre italianizzata. L’effetto è simile a:

òccollegàt(o)ilmàusalcompiùter.

Se marcassimo questa frase con dei cambi di lingua sulle presunte parole inglesi (<p>Ho collegato il <span lang="en">mouse</span> al <span lang="en">computer.</span></p>), rischieremmo di renderla incomprensibile per un ascoltatore italiano, una volta che la frase fosse pronunciata da una sintesi vocale che passasse in successione, come richiedono i cambi di lingua inseriti nel codice, dalle regole fonetiche dell’italiano a quelle dell’inglese, poi di nuovo a quelle dell’italiano e poi ancora a quelle dell’inglese, e usasse in tutto ciò due voci differenti, una per l’italiano e una per l’inglese.

Il nodo del problema è che l’essere umano è “progettato” per parlare una sola lingua alla volta: non si può parlare contemporaneamente italiano e inglese. Se una parola straniera viene pronunciata da un italiano in una frase italiana, la sua pronuncia viene automaticamente (e inconsapevolmente) modificata in modo da amalgamarla alla pronuncia delle parole italiane della frase. Allo stato attuale, solo le sintesi vocali più costose e sofisticate cominciano a possedere questa capacità. Le soluzioni più economiche non solo usano voci diverse per lingue diverse, ma pronunciano in genere ogni parola secondo le esatte regole fonetiche della lingua a cui, secondo il software o il codice di marcatura, la parola appartiene. E questo, sembrerà strano a chi non ha dimestichezza con le lingue, può avere un esito deleterio sulla comprensione e, di conseguenza, sull’accessibilità (un fatto confermato da diversi non vedenti utilizzatori di sintesi vocali).

A peggiorare, infine, le cose, c’è il problema della lentezza dei cambi di lingua nei sistemi hardware meno performanti: scaricare un motore di sintesi e poi caricarne un altro per pronunciare una sola parola straniera, e poi subito dopo ritornare alla lingua precedente, e ripetere il procedimento magari due o tre volte nella stessa frase, è qualcosa che può rendere la lettura di un brano da parte di uno screen reader frammentata da pause lunghe e fastidiose, con effetti ulteriormente peggiorativi sulla comprensione del brano e sull’interesse dell’utente.

Inizio pagina

Suggerimenti per un’applicazione accessibile del punto di controllo 4.1

Giunti a questo punto, è utile consolidare quanto è stato detto fin qui, fornendo una serie di indicazioni pratiche su come applicare il punto di controllo 4.1 in modi che favoriscano l’accessibilità invece di ostacolarla. Ciò, naturalmente, secondo l’opinione e l’esperienza dell’autore, che non ha alcuna pretesa di imporre le proprie conclusioni come verità assolute.

Gli esempi successivi considerano l’italiano come lingua principale del documento e usano HTML come linguaggio di marcatura.

Suggerimento 1. Marcare i frammenti di senso compiuto

Marcare come cambi di lingua i frammenti di testo di senso compiuto, scritti in una lingua diversa da quella primaria del documento.

Suggerimento 2. Titoli di opere straniere

Marcare come cambi di lingua i titoli di opere straniere inserite in una bibliografia.

Suggerimento 3. Parole scritte in un diverso alfabeto

Marcare come cambi di lingua le parole straniere scritte in un diverso alfabeto e/o quelle inserite in una frase con lo scopo deliberato di attirare l’attenzione del lettore sulla loro pronuncia o sul loro significato.

Suggerimento 4. Voci di menu

NON marcare come cambi di lingua le parole straniere usate come voci di menu o di liste.

Suggerimento 5. Nomi propri stranieri

NON marcare come cambi di lingua i nomi propri stranieri (a meno che non siano scritti in un alfabeto diverso).

Suggerimento 6. Non marcare i prestiti linguistici

NON marcare come cambi di lingua i nomi comuni d’origine straniera entrati nell’uso (anche specialistico) della lingua italiana.

I suggerimenti precedenti, per quanto offrano un ampio spettro di soluzioni per l’accessibilità dei cambi di lingua, non coprono tutte le situazioni possibili. Le lingue sono fenomeni estremamente complessi e non è semplice rendere veramente e largamente comprensibili testi che contengono inserti in altre lingue e termini stranieri importati. Perciò, la migliore raccomandazione di accessibilità in questo campo è senza alcun dubbio quella del suggerimento 7.

Suggerimento 7. Evitare, se possibile, l’uso di termini stranieri

Evitare l’uso di termini stranieri ogni volta che sia possibile, sostituendoli con equivalenti tratti dalla lingua principale del documento.

Nell’esempio positivo abbiamo lasciato l’inglese “low-cost”, anche se avrebbe potuto essere sostituito con l’italiano “a basso costo”. Lo scopo non è, infatti, quello di inseguire un assoluto e anacronistico purismo lessicale, ma quello di evitare l’uso di termini stranieri non necessari. L’espressione “low-cost” è oggi di uso talmente frequente, quando si parla di viaggi in aereo, da non richiedere la ricerca di un equivalente italiano, che, anzi, se usato, potrebbe essere causa di fraintendimenti (“una compagnia a basso costo sarà la stessa cosa di una compagnia low-cost?”).

È chiaro che la valutazione di quali parole straniere evitare e quali, invece, utilizzare dipende in larga misura dal pubblico a cui il sito si rivolge e dalla sensibilità degli autori. In linea di massima resta ferma però la raccomandazione di ricorrere all’uso di termini stranieri solo in caso di mancanza di adeguati equivalenti nella lingua del documento, in modo da evitare alla radice la necessità di trovare compromessi più o meno accessibili per risolvere gli oggettivi problemi di comprensibilità legati ai cambi di lingua.

Si noti, infine, che abbiamo usato lo stesso periodo, prima come esempio positivo (Listato 7.9, relativamente alla raccomandazione di non marcare come cambi di lingua i nomi comuni stranieri usati all’interno di una frase in italiano) e poi come esempio negativo (Listato 7.12), una volta che abbiamo spostato l’attenzione sulla scelta delle parole piuttosto che sull’uso della marcatura per i cambi di lingua: l’accessibilità ha più livelli e più facce.

Inizio pagina

Considerazioni finali sul tema dei cambi di lingua

Prima di abbandonare l’argomento, proponiamo due note su cui riteniamo importante attirare l’attenzione del lettore:

1. HTML e XHTML sono strumenti non adatti a gestire un sintetizzatore vocale in tutte le particolarità di pronuncia e lettura che esulano dalle sue “conoscenze” predefinite;
2. dovrebbe essere compito dei produttori di programmi di sintesi vocale, non degli sviluppatori, riuscire a far sì che le voci sintetiche pronuncino le parole di origine straniera usate comunemente in una lingua in modo conforme alle abitudini degli umani che parlano quella lingua.

Quanto al primo punto, HTML e XHTML dispongono solo degli attributi lang, xml:lang e hreflang per definire informazioni relative alla lingua. Davvero troppo poco, se si vuole ottenere da una sintesi vocale sottigliezze di tipo “umano” nella lettura dei testi. Anche i fogli di stile acustici (Aural style sheets ), per quanto siano ricchi di possibilità di personalizzazione in fatto di caratteristiche delle voci e dei suoni emessi da un sintetizzatore, sono alla fine uno strumento di presentazione, non di definizione del contenuto: non possono, cioè, imporre a un motore di sintesi di pronunciare una parola secondo regole fonetiche diverse da quelle che il motore applica per la lingua impostata.

Per quanto riguarda, invece, il secondo punto, la miglior soluzione non è, come abbiamo suggerito, di infarcire il codice di marcatura di cambi di lingua su singole parole, né è pensabile che autori e sviluppatori abbiano il tempo e le competenze linguistiche per analizzare riga per riga tutti i documenti che pubblicano sul Web, alla ricerca delle parole con pronuncia “diversa”. L’unica soluzione realmente praticabile è che i produttori di programmi di sintesi vocale riescano a incorporare dizionari di pronuncia progressivamente aggiornati con la pronuncia italiana delle parole straniere di uso più comune, cosa che, per la verità, già viene fatta da alcuni produttori.

Loquendo ), per esempio, nota società che realizza e commercializza motori di sintesi vocale, ha raggiunto ottimi livelli, per quanto riguarda la capacità delle sue voci sintetiche di leggere, così come li leggerebbe un parlante umano, cioè adattandoli parzialmente alle abitudini di pronuncia della propria lingua, i termini stranieri inseriti nella lingua principale del documento.

È possibile provare direttamente questa funzionalità, collegandosi alla pagina dimostrativa , da cui si possono selezionare numerose voci italiane. Queste sono in grado di leggere frasi in inglese (o in una qualsiasi delle altre lingue supportate) inserite all’interno di testi in italiano, con la particolarità, importantissima per la comprensibilità dei testi, che la lettura del brano in inglese viene fatta dalla stessa voce che legge l’italiano.

Le voci di Loquendo che è possibile provare sul sito della società hanno anche un’altra utile capacità: se si inserisce nel campo di immissione testo una frase in italiano che contiene nomi propri con pronuncia non italiana, questi verranno letti, se sono noti al programma, con la pronuncia straniera del caso, senza che vi sia necessità di marcare alcunché nel codice. Per esempio, i nomi di città contenuti nel seguente periodo, usato come test, sono stati pronunciati tutti correttamente (o meglio, nel modo in cui li pronuncerebbe un italiano che tentasse di imitare la loro pronuncia originale):

Ho fatto un viaggio da Beijing a New York. In Francia mi sono fermato a Nancy e a Nantes.

Un buon livello è stato raggiunto dalle voci italiane di Loquendo anche nella pronuncia italianizzata di nomi comuni stranieri. Abbiamo fatto delle prove, usando il testo dei Listati 7.9 e 7.12, che contiene diverse parole d’origine inglese. La voce sintetica di Paola, senza che avessimo inserito alcuna marcatura di cambio di lingua, le ha pronunciate quasi tutte così come le pronuncerebbe un italiano: “fàil” per file, “daunlòd” per download, “ab” per hub, “lòucost” per low-cost. L’unica eccezione è stata la parola briefing, che è stata pronunciata “bràifing”, quasi che il software volesse fare il verso al Mike Bongiorno imitato da Fiorello nella trasmissione radiofonica Viva Radio 2...

Il comportamento delle voci di Loquendo è esattamente quel che serve per risolvere in modo realmente accessibile i problemi di cui abbiamo discusso in questo lungo commento al punto di controllo 4.1 delle WCAG 1.0.

Tuttavia, un grosso aiuto al miglioramento delle capacità di pronuncia delle sintesi vocali può essere fornito dagli stessi utenti, utilizzando le funzioni di questi sofisticati software per incorporare nuovi vocaboli e nuove pronunce nei propri dizionari. Si veda in proposito la guida di Nunziante Esposito alla personalizzazione del dizionario di pronunce di JAWS .

Inizio pagina

Inizio pagina

Punto di controllo 4.2, priorità 3

A proposito del punto di controllo 4.2, ci sono due questioni da considerare: la prima riguarda l’opportunità, la seconda il modo di soddisfare la sua richiesta.

Sull’opportunità di applicare il punto di controllo 4.2

È necessario segnalare sempre, alla prima occorrenza di una forma abbreviata in un documento, qual è la sua forma estesa? A nostro avviso, no (questo è uno dei casi in cui contestiamo la validità generale del suggerimento fornito dalle WCAG 1.0). Si usano infatti in italiano, e ovviamente anche in altre lingue, sigle che sono diventate di uso talmente comune da avere del tutto oscurato la forma estesa da cui sono derivate. Ricordare perciò questa forma estesa, soprattutto quando non è necessario per la comprensione del contenuto, è inutile, se non addirittura dannoso.

Prendiamo il caso di “CD-ROM”. È un acronimo d’uso molto comune, che fa venire in mente l’oggetto che rappresenta, un supporto ottico per archiviare dati digitali, molto più di quanto non faccia la sua forma estesa: “Compact Disc Read Only Memory”. Se, in un documento web che non parla dell’oggetto fisico (il disco) ma del suo contenuto, associassimo alla prima occorrenza della sigla “CD-ROM” la sua forma estesa, nella migliore delle ipotesi avremmo dato un’informazione inutile, nella peggiore avremmo creato nel lettore un fattore di confusione. Diverso sarebbe il caso, se “CD-ROM” comparisse in un documento che parla dei vari tipi di dischi su cui è possibile registrare dati in forma digitale. In quel caso sarebbe corretto fornire la forma estesa di tutte le sigle in discussione: per esempio “Compact Disc Recordable” per “CD-R”, “Compact Disc Re-Writable” per “CD-RW”, “Compact Disc Interactive” per “CD-i”.

Un’interpretazione legalistica del punto di controllo 4.2 porterebbe, insomma, gli autori di pagine web a un superlavoro di controllo dei testi e a un inserimento di forme estese sostanzialmente inutili ai fini dell’accessibilità. Basti pensare alle numerose sigle che, a furia di usarle, hanno perso il riferimento alla loro forma estesa, al punto che molti ignorano persino che si tratti di sigle (soprattutto se si trovano scritte correntemente in caratteri minuscoli). “Radar”, per esempio, è un acronimo derivato dall’inglese radio detection and ranging ("radiorilevamento e misurazione di distanza") e si usa universalmente al posto della sua forma estesa. Lo stesso succede per “laser” (Light Amplification by Stimulated Emission of Radiation, "amplificazione della luce per mezzo dell’emissione stimolata di radiazioni"), “DNA” (DeoxyriboNucleic Acid), e tante altre.

Alla luce di tali considerazioni, ci sembra che il punto di controllo 4.2 non dovrebbe essere applicato in ogni occasione, ma solo quando fornire la forma estesa delle abbreviazioni serve realmente a favorire la comprensione del contenuto. Tale valutazione dipende dall’argomento trattato e dai destinatari a cui un documento si rivolge; e spetta ad autori e redattori dei contenuti, non agli sviluppatori, che dovrebbero limitarsi a tradurre in codice di marcatura le indicazioni dei primi.

Gli autori di contenuti per il Web, dal canto loro, dovrebbero già sapere che chiarire le sigle poco note o di dubbia interpretazione è il minimo che si possa fare, se si vuole sperare di essere compresi senza difficoltà dai propri lettori, soprattutto da quelli meno esperti dell’argomento trattato.

Inizio pagina

Sul modo di applicare il punto di controllo 4.2

La tecnica usuale per associare a una sigla la relativa forma estesa consiste, in HTML e in XHTML, nell’usare l’elemento ABBR o l’elemento ACRONYM. Per entrambi il funzionamento è lo stesso: la forma estesa va inserita come valore dell’attributo title dell’elemento, nel modo mostrato dal seguente esempio, tratto dalle tecniche HTML associate alle WCAG 1.0.

Sono anni che gli sviluppatori discutono sulle presunte differenze tra i due elementi e sull’opportunità di usare l’uno oppure l’altro. In verità ci sembra una discussione piuttosto oziosa, dal momento che entrambi gli elementi, all’atto pratico, fanno esattamente la stessa cosa: creano un’associazione a livello di codice tra una forma abbreviata e una forma estesa.

Dal punto di vista semantico, un acronimo è un tipo di abbreviazione, ottenuto prendendo le lettere iniziali di più parole tra loro collegate, come in “CGIL”, che sta per “Confederazione Generale Italiana del Lavoro”. Ma non succede sempre così: “motel” è costituito per esempio da “moto hotel”, in cui vengono prese la parte iniziale della parola “moto” e la parte finale della parola “hotel”.

Un’abbreviazione è invece qualcosa di più generale: può essere costituita dalla parte iniziale di una singola parola (“s.” per “santo”, “Sig.” per “Signore”), dalla contrazione di una parola (“cfr.” per “confronta”) o da operazioni simili fatte su un gruppo di parole tra loro collegate. In sostanza, non c’era alcun bisogno, neppure dal punto di vista semantico, di avere in HTML e XHTML due elementi diversi per svolgere una funzione pressoché identica. Fortunatamente, in XHTML 2.0 il fattore di confusione sarà finalmente eliminato, perché, se sarà confermata la struttura dell’attuale bozza, l’elemento ACRONYM risulterà abolito, a vantaggio di ABBR, che invece sopravviverà.

Per quanto riguarda l’implementazione da parte dei browser, Internet Explorer 6 ignora completamente sia ABBR sia ACRONYM, non mostrando nella pagina alcun segno visibile della loro presenza (ma, passando il puntatore del mouse sulle sigle marcate con ACRONYM, compare un piccolo messaggio temporaneo, chiamato in inglese tooltip, che mostra in caratteri minuscoli e non ingrandibili la forma estesa della sigla). Internet Explorer 7 fa comparire il messaggino al passaggio del mouse su entrambi gli elementi, ma sempre senza alcun segno grafico sotto i testi marcati con ABBR e ACRONYM, che possa suggerire all’utente la presenza di un’informazione nascosta.

Gli altri browser si comportano un po’ meglio: Opera, Firefox, Camino e iCab mostrano una sottile linea punteggiata sotto il testo delle sigle marcate con i due elementi, e, al passaggio del mouse, fanno comparire in entrambi i casi un tooltip analogo a quello mostrato da Internet Explorer. Gli screen reader JAWS e Window-Eyes possono essere configurati per leggere il testo inserito nell’attributo title dei testi marcati con ABBR e ACRONYM, ma non lo leggono in modo predefinito.

Il supporto dei programmi utente ai due elementi è insomma, soprattutto dal punto di vista visuale, tra lo scadente e il pessimo. Ragion per cui, usare ABBR o ACRONYM per render conto all’utente della forma estesa di una sigla è qualcosa che, allo stato attuale, ha poco a che fare con l’accessibilità. Suggeriamo pertanto di inserire la forma estesa di una sigla o di un’abbreviazione, nei casi in cui si ritenga utile fornirla, direttamente nel testo visibile di un documento. Nel seguente esempio sono fornite tra parentesi le forme estese di tre note sigle usate in biologia e, per migliorare la comprensibilità, è stato usato direttamente l’equivalente italiano degli acronimi inglesi:

Il DNA (acido desossiribonucleico) è la molecola organica in cui sono codificate le informazioni genetiche di ogni individuo vivente. La sua replicazione è un complicato processo che coinvolge altre molecole, tra cui RNA (acido ribonucleico) e ATP (adenosintrifosfato).

Questa è di gran lunga la soluzione più accessibile per chiarire il significato delle forme abbreviate: il testo semplice, infatti, come abbiamo già chiarito parlando del concetto di equivalente, è lo strumento che meglio si presta alla fruizione in diverse modalità e con diversi dispositivi. È visibile con qualsiasi browser e, a meno di errori dello sviluppatore, può essere ingrandito senza limiti; è inoltre direttamente leggibile da un sintetizzatore vocale: il testo semplice, insomma, non soffre delle numerose limitazioni con cui i programmi utente trattano i contenuti marcati con ABBR e ACRONYM.

Se un’abbreviazione ricorre più volte in una serie di documenti collegati e si vuole evitare di fornirne la forma estesa in ogni documento, una soluzione praticabile è quella di collegare le singole occorrenze dell’abbreviazione al punto preciso del documento in cui viene fornita la forma estesa. Una soluzione ancor più sintetica consiste nel creare un glossario che elenca tutte le sigle usate in una raccolta di documenti e le associa alle relative forme estese; il glossario andrà poi collegato a ogni documento della raccolta, tramite un avviso posizionato e formattato in modo tale da non passare inosservato.

Inizio pagina

Punto di controllo 4.3, priorità 3

Ragioni e metodi per identificare la lingua del documento

Il punto di controllo 4.3 fa sorgere tre domande:

• a cosa serve identificare la lingua principale di un documento?
• Cosa si intende per lingua principale?
• Come si fa a specificarla?

A tutte e tre risponde una Nota del W3C, del 12 aprile 2007, intitolata Internationalization best Practices: Specifying Language in XHTML & HTML Content .

A cosa serve dichiarare la lingua del documento

Vediamo in primo luogo a cosa serve specificare la lingua. Lo spiega il paragrafo 2 del documento W3C:

Esistono già applicazioni che possono utilizzare l’informazione sulla lingua del contenuto (...), per inviare agli utenti le informazioni o lo stile più pertinenti basati sulle loro preferenze linguistiche. Maggiore è la quantità di contenuti marcati, e marcati correttamente, più utili e pervasive diventeranno tali applicazioni.

Le informazioni sulla lingua sono utili per cose come strumenti autoriali, strumenti di traduzione, accessibilità, selezione dei caratteri, resa della pagina, ricerca e scripting.

A proposito dello sviluppo di future applicazioni basate sulla presenza di informazioni linguistiche nei documenti, il testo citato aggiunge un’interessante annotazione:

Chi non vede l’applicazione delle informazioni sulla lingua, non fornisce tali informazioni per quanto riguarda i propri contenuti; e applicazioni dipendenti dalla lingua vengono sviluppate con lentezza finché tali informazioni non saranno ampiamente disponibili. Questo circolo vizioso può essere spezzato dagli autori di contenuti, prendendo ora l’iniziativa di dichiarare informazioni sulla lingua. Ciò è di solito molto facile a farsi e non ha conseguenze negative.

La lingua del pubblico di destinazione e la lingua per il trattamento del testo

In HTML e XHTML esistono due tipi di informazioni sulla lingua di un documento: quelle relative all’intero documento e quelle relative a un singolo frammento di documento, che può essere limitato al testo racchiuso anche da un solo elemento nel codice di marcatura.

Nel primo caso, la dichiarazione deve identificare la lingua in cui legge e parla quella che in inglese è definita intended audience, cioè il pubblico a cui il documento, nella sua interezza, è destinato: è questa l’informazione che il punto di controllo 4.3 chiede di specificare.

Nel secondo caso, invece, che corrisponde ai cambiamenti di lingua analizzati nel commento al punto di controllo 4.1, ciò che deve essere specificato è il text-processing language, cioè la lingua per il trattamento di frammenti di testo da parte di software specializzati, come possono essere i browser vocali.

I paragrafi 3.1 e 3.2 della Nota W3C forniscono ulteriori dettagli sulla distinzione tra i due tipi d’informazione. Ci interessano in particolare, in questo commento al punto di controllo 4.3, i chiarimenti sulla lingua per il pubblico di destinazione.

La lingua del pubblico di destinazione (intended audience) non include tutte le lingue usate in un documento. Molti documenti sul Web contengono frammenti incorporati di contenuti in lingue differenti, mentre la pagina è rivolta chiaramente a persone che parlano una specifica lingua. Per esempio una guida tedesca alla città di Pechino può contenere frasi utili in cinese, ma è destinata a un pubblico che parla il tedesco, non il cinese.

D’altra parte, è anche possibile immaginare una situazione in cui un documento contiene contenuti uguali o paralleli in più di una lingua. Per esempio, una pagina web può accogliere i lettori canadesi con contenuti in francese nella colonna di sinistra e con i medesimi contenuti in inglese nella colonna di destra. Qui il documento è destinato in ugual misura a parlanti di entrambe le lingue, sicché le lingue del pubblico sono due. Questa situazione non è comune sul Web come lo è per il materiale a stampa, dal momento che è facile creare sul Web collegamenti a due pagine separate per pubblici differenti, ma tuttavia capita quando vi sono comunità multilingue. Un altro caso d’uso è un blog o un sito informativo che si rivolgono a una comunità multilingue, nei quali alcuni articoli su una pagina sono in una lingua e alcuni in un’altra.

Vi sono inoltre pagine, in cui le informazioni di navigazione, compreso il titolo della pagina, sono in una lingua, ma il contenuto vero e proprio della pagina è in un’altra. Benché questa non sia necessariamente una buona pratica, ciò non toglie che la lingua del pubblico di destinazione sia di solito quella del contenuto, indipendentemente da quale sia la lingua all’inizio del codice sorgente del documento.

Metodi per dichiarare la lingua principale del documento

Non considerando i cambi di lingua dichiarati a livello dei singoli elementi, vi sono tre modi in cui può essere dichiarata la lingua, o le lingue, dell’intero documento:

• nelle intestazioni HTTP inviate dal server al client;
• nell’elemento HTML;
• in un elemento META.

All’interno della Nota W3C che stiamo analizzando, c’è un paragrafo, il quarto, intitolato Mechanisms for Declaring Language in HTML , che fornisce esempi per ciascuno dei tre metodi. Il Listato 7.18 mostra uno di questi esempi: una serie di intestazioni HTTP inviate da un web server Apache. L’ultima riga, Content-language, specifica l’inglese, tramite la sigla en, come lingua primaria del documento.

Con l’intestazione Content-language possono essere dichiarate anche più lingue contemporaneamente, separandole con virgole. Dichiarare la lingua mediante intestazioni HTTP richiede di avere accesso alle impostazioni del server su cui sono ospitate le pagine web influenzate da questa impostazione.

Il secondo metodo, la dichiarazione della lingua primaria del documento nell’elemento HTML, è più semplice e, inoltre, ha la precedenza sulla dichiarazione mediante intestazioni HTTP. Può essere usato, però, per dichiarare una sola lingua per volta. Infatti i valori degli attributi lang e xml:lang, che servono per specificare la lingua del documento nell’elemento HTML (o la lingua di un frammento di testo, in un elemento di livello inferiore), possono avere come valore un unico codice di lingua per volta.

Il codice del Listato 7.19, che dichiara come lingua principale la variante canadese del francese, è tipico di un documento XHTML servito con il MIME type text/html: un uso improprio, ma molto comune (si veda in proposito il paragrafo Pro e contro nell’uso di XHTML, nel Capitolo 16 di questo libro). In un caso simile, devono essere presenti sia l’attributo lang che l’attributo xml:lang. Il rapporto tra questi due attributi viene chiarito da uno dei massimi esperti di internazionalizzazione presso il W3C, Richard Ishida, in una guida del 2005 intitolata Declaring Language in XHTML and HTML :

Quando si serve XHTML come text/html, si dovrebbero usare sia l’attributo lang sia l’attributo xml:lang. L’attributo xml:lang è il modo standard di identificare le informazioni sulla lingua in XML. [...] L’attributo xml:lang non ha una reale utilità se si tratta di gestire il file come HTML, ma prende il sopravvento sull’attributo lang ogni volta che il documento viene trattato come XML, in caso, per esempio, di script o di validazione.

Se delle pagine XHTML 1.0 vengono servite come XML (cioè usando un MIME type come application/xhtml+xml), o si stanno servendo pagine XHTML 1.1, non c’è bisogno dell’attributo lang, dal momento che lang fa parte del linguaggio HTML. Basterà il solo attributo xml:lang.

Se, infine, il documento è scritto in HTML, è sufficiente il solo attributo lang, come nell’esempio seguente.

Veniamo all’ultimo metodo: la dichiarazione della lingua principale del documento in un elemento META. Ne vediamo un esempio nel Listato 7.22, nel quale vengono dichiarate tre lingue primarie: l’inglese, il francese e lo spagnolo.

A proposito di quest’uso dell’elemento META, Richard Ishida spiega:

In teoria, potrebbe essere una buona cosa dichiarare le informazioni sul linguaggio primario in un elemento META. [...] In pratica, tuttavia, sembra che esso sia poco usato al momento.

In realtà, le Specifiche HTML 4.01 non nominano neppure la possibilità di impostare la lingua del documento per mezzo dell’elemento META. Nel paragrafo 8.1.2 (Inheritance of Language Codes , "Eredità dei codici di lingua"), le Specifiche forniscono un preciso ordine di precedenze circa l’eredità dei codici di lingua.

Un elemento eredita le informazioni sul codice di lingua in base al seguente ordine di precedenza (dal più alto al più basso):

• l’attributo lang impostato per l’elemento stesso;
• il più vicino elemento genitore che abbia l’attributo lang impostato (l’attributo lang, cioè, viene ereditato);
• l’intestazione HTTP Content-Language (che può essere configurata in un server);
• i valori predefiniti del programma utente e le preferenze dell’utente.

In conclusione, il metodo più diretto e potente per dichiarare la lingua principale del documento resta l’uso di lang e/o xml:lang nell’elemento HTML. Nei rari o rarissimi casi, in cui è necessario dichiarare più di una lingua principale, è possibile usare l’intestazione HTTP Content-language, intervenendo sulle impostazioni del web server.