Vai ai contenuti

LAU



Home > realizzare > accessibilità: contenuti > Acronimi, abbreviazioni e cambi di lingua


Acronimi, abbreviazioni e cambi di lingua

Come scrivere testi accessibili attraverso il corretto utilizzo dei tag per gli acronimi, le abbreviazioni e i cambi di lingua.

a cura di: Fabio Regina | 7 febbraio 2006


1. Uso di abbreviazioni ed acronimi

Tra i vari suggerimenti forniti dalle WCAG per rendere accessibili i documenti sul Web vi è quello di marcare gli acronimi e le abbreviazioni e segnare i cambi di lingua. Infatti, una delle difficoltà che il lettore spesso incontra nella fruizione dei contenuti nel Web è quella di ritrovarsi di fronte documenti stracolmi di sigle di significato talvolta incomprensibili.

Per evitare tali inconvenienti il punto di controllo 4.2 delle WCAG 1.0 [link esterno] suggerisce un metodo per renderli accessibili.
È infatti buona norma fornire la forma estesa di tutte le sigle e abbreviazioni utilizzate marcandole con i tag <acronym> o <abbr>, rispettivamente per gli acronimi e per le abbreviazioni.

Inoltre secondo il punto di controllo 4.2 delle WCAG 1.0 non tutte le occorrenze di una medesima sigla devono essere marcate con <abbr> e <acronym> bensì solo la prima occorrenza.

Codice XHTML (tag <acronym>):

Testo originale

<p>Raccomandazione del W3C...<p>

Testo accessibile

<p>Raccomandazione del 
<acronym lang=”en” 
title=”World Wide Web Consortium”>W3C
</acronym>...
<p>

Codice XHTML (tag <abbr>):

Testo originale

<p>Sec. 508<p>

Testo accessibile

<p>La<abbr lang=”en” title=”Section”>Sec.
</abbr> 508<p>

Da un punto di vista semantico le parole W3C e Sec. sono state marcate correttamente, rispettivamente come acronimo e abbreviazione; ciò significa ad esempio che i lettori vocali, ogni qualvolta leggeranno parole marcate come acronimi o abbreviazioni, li segnaleranno come tali.
Se da una parte, dal punto di vista della struttura semantica, l'utilizzo dei tag <acronym> e <abbr> risulta essere una scelta corretta, dall'altra risulta altrettanto corretta la scelta di curarne anche l'aspetto, ovvero la loro visualizazione sui browser; infatti, non tutti i browser riescono a farli visualizzare alla stessa maniera.

Più avanti mostreremo alcune delle tecniche più diffuse per visualizzare gli acronimi e le abbreviazioni alla stessa maniera su tutti i browser.

Come si può osservare dagli esempi, ai tag <acronym> e <abbr> è associato l'attributo "title" che specifica il loro valore; è anche possibile notare come all'attributo "title" venga associato anche l'attributo "lang" che specifica in quale lingua si esprime.
Uno dei problemi cui si va incontro nell'uso degli acronimi e delle abbreviazioni consiste nel riuscire a distinguerli correttamente. Infatti, molto spesso si fa confusione.

Lo stesso W3C definisce parole come W3C, WAI, HTTP come abbreviazioni quando in realtà possono essere considerate degli acronimi (Worl Wide Web Consortium per "W3C", WAI per "Web Accessibility Initiative" e HTTP per "Hyper Text Transfer Protocol").

Ma allora dove sta la verità? Purtroppo le WCAG 1.0 non ci chiariscono il dubbio sull'uso corretto da farne poiché, da una parte invitano ad utilizzare due tag di marcatura diversi, dall'altro non danno delle indicazioni precise su quando utilizzare l'uno e quando l'altro.
La parola W3C, ad esempio, potrebbe essere considerata come un'abbreviazione in quanto risulta caratterizzata dalla riduzione delle lettere che compongono il nome completo ("World Wide Web Consortium") con l'aggiunta del 3 che rappresenta le 3 W; invece WAI risulta problematico da classificare sia come abbreviazione sia come acronimo.

Tali problemi si pongono proprio perché l'acronimo è una sottocategoria di abbreviazione.
Ad esempio, il WWW, marcato nelle specifiche HTML come abbreviazione, potrebbe essere ugualmente marcato come acronimo, visto che – così come prevede la regola di formazione degli acronimi – è formato dalle iniziali delle tre parole che compongono la sigla.

Comunque, dal punto di vista dell'accessibilità la cosa che conta veramente è avere un sistema per fornire la forma estesa della contrazione di una o più parole, non importa se si tratta di abbreviazioni o acronimi.

torna su

2. Supporto dei browser

Un dei problemi generati dall'uso di <acronym> e <abbr> è quello relativo al supporto dei browser. La visualizzazione degli acronimi e delle abbreviazioni, infatti, varia a seconda del browser utilizzato.

Di seguito sono mostrate due tabelle che sintetizzano come i due tag vengono supportati da alcuni browser:

Il tag <acronym>
browser <acronym>
Firefox 1.5 Sottolinea automaticamente l'acronimo con una linea punteggiata e, quando l'utente passa il cursore sull'acronimo, visualizza il testo alternativo.
Internet Explorer 6.0 Visualizza il testo alternativo ma non segna l'acronimo con una linea punteggiata.
Opera 8.0 Sottolinea automaticamente l'acronimo con una linea punteggiata e, quando l'utente passa il cursore sull'acronimo, visualizza la descrizione come tooltip.
Netscape 8.0 Sottolinea automaticamente l'acronimo con una linea punteggiata e, quando l'utente passa il cursore sull'acronimo, visualizza il testo alternativo.
Il tag <abbr>
browser <abbr>
Firefox 1.5 Sottolinea automaticamente l'acronimo con una linea punteggiata e, quando l'utente passa il cursore sull'acronimo, visualizza il testo alternativo.
Internet Explorer 6.0 Non visualizza né il testo alternativo né la linea punteggiata.
Opera 8.0 Sottolinea automaticamente l'acronimo con una linea punteggiata e, quando l'utente passa il cursore sull'acronimo visualizza la descrizione come tooltip.
Netscape 8.0 Sottolinea automaticamente l'acronimo con una linea punteggiata e, quando l'utente passa il cursore sull'acronimo, visualizza il testo alternativo.

Da questi due esempi si evince come i maggiori problemi si riscontrino con Internet Explorer. Mentre browser come Mozilla Firefox sottolineano automaticamente l'acronimo con una linea punteggiata, Internet Explorer non solo non riconosce <abbr>, ma non fa nulla di default per segnalare <acronym>; infatti anche se visualizza il testo alternativo, il testo non viene evidenziato con una tratteggiatura che possa farlo distinguere.
Attraverso l'uso dei fogli di stile è possibile fare apparire la linea tratteggiata in tutti i browser.
La regola che viene utilizzata è la seguente:

CSS:

acronym, abbr{
border-bottom: 1px dotted black;
}

Se applichiamo questo foglio di stile al codice XHTML riportato sopra, otteniamo il seguente risultato:

Risultato: W3C, Sec. 508

Questa proprietà crea un bordo inferiore punteggiato; se invece viene utilizzato dashed anzichè dotted, si crea un bordo tratteggiato.
Naturalmente grazie ai fogli di stile è possibile dare formattazioni diverse ai tag <acronym> e <abbr>, ma la tecnica descritta sopra sembra essere la più indicata e anche la più utilizzata. Infatti è importante che il loro aspetto sia molto diverso da un link.
Questo è importante perché le parole usate come acronimi o abbreviazioni non devono confondere l'utente spingendolo a cliccare.

È per tale ragione che il colore dev'essere quello del testo o comunque un colore diverso da quello dei link, e la sottolineatura dev'essere tratteggiata e non continua.
Va precisato che il CSS appena decritto non consente a Internet Explorer di riconoscere <abbr>.
Ecco perché per superare i limiti di Internet Explorer è consigliabile ricorrere ad un'altra tecnica: inserire uno <span> dentro l'elemento <abbr>.

La tecnica utilizzata è esposta di seguito:

Codice XHTML:

<abbr title="confronta">
<span class="nome_classe" title="confronta">
cfr.
</span>
</abbr>

CSS:

abbr, acronym, .nome_classe{
border-bottom: 1px dotted black;
}

Tra i più diffusi metodi volti ad identificare in modo non equivoco gli acronimi vi è quello di far assumere al cursore la forma di un punto interrogativo - e non della solita manina - nel momento in cui l'utente si posiziona sull'acronimo o sull'abbreviazione marcati.

La tecnica utilizzata è la seguente:

CSS:

abbr, acronym, .nome_classe{
border-bottom: 1px dotted black;
cursor:help;
}

Se applichiamo questo foglio di stile al codice XHTML riportato sopra per gli acronimi e le abbreviazioni, otteniamo il seguente risultato:

Risultato: W3C, Sec. 508.

torna su

3. Segnalare i cambi di lingua

Segnalare i cambi di lingua è molto utile per chi usa un sintetizzatore vocale.
Gli screen reader settano la lingua del documento in base all'impostazione della lingua sulla DOCTYPE.
Per esempio, una pagina web, in cui nella DOCTYPE è stato settato l'attributo lang="it", sarà letta dallo screen reader in lingua italiana.

Tuttavia, capita spesso che in una pagina si trovino numerose parole in lingua diversa da quella di default.
In questi casi è opportuno segnalare nel codice di marcatura i cambi di lingua presenti nel testo.

Ad esempio:

Codice XHTML:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it" lang="it" <head>
<title>Titolo documento</title>
</head>
<body>
<p>Oggi l’economia ruota intorno ad un <span lang=”en” xml:lang=”en”>business </span>globale.</p> </body>
</html>

In questo esempio la parola business (marcata con lang="en", in quanto parola inglese, e posto come attributo di <span>) verrà pronunciata dagli screen reader con la giusta dizione inglese.
In XHTML 1.1 a lang="en", si aggiunge xml:lang="en".

Nonostante le WCAG 1.0 raccomandano di marcare i cambi di lingua senza eccezioni, spesso si tende a non marcare tutte le parole in lingua straniera.
Questo accade ad esempio quando alcune parole straniere, pur essendo lette "all'italiana" dai sintetizzatori vocali, vengono ugualmente comprese dall'ascoltatore.
In questi casi la mancata marcatura della parola straniera può risultare un buon espediente per non appesantire il codice visto che, durante la lettura della pagina, il cambio automatico della lingua può generare un rallentamento (soprattutto per le attrezzature hardware/software poco potenti).

Quindi il consiglio è quello di evitare di marcare come cambi di lingua:

  • le parole straniere che, se pronunciate all'italiana dal sintetizzatore vocale, risultano comunque comprensibili per l'ascoltatore;
  • le parole che sono state assorbite dalla lingua di default espressa nel DOCTYPE; (nel caso della lingua italiana potrebbe essere ad esempio il rapporto con la lingua inglese).

In ogni caso la scelta più saggia risulta essere quella di ridurre al minimo l'uso di parole straniere.
Peraltro, non tutti gli screen reader supportano il cambio di lingua (per una trattazione dettagliata di tale argomento si rimanda all'articolo "Cambi di lingua e screen reader").

torna su

4. Risorse in rete sull'uso di acronimi, abbreviazioni e cambi di lingua

torna su

[ Torna all’inizio della pagina ]



Sito realizzato dal Laboratorio di Accessibilità e Usabilità del CSI-Piemonte - Dichiarazione di accessibilità

[ Torna all’inizio della pagina ]