Abbreviazioni e acronimi: usabilità e accessibilità | Usabile.it

Usabile.it

usabilità, accessibilità e interaction-design per il web

home » Articoli » Abbreviazioni e acronimi: usabilità e accessibilità

14/01/2003

Abbreviazioni e acronimi: usabilità e accessibilità

[di Maurizio Boscarol]

Nel tentativo di perseguire una miglior accessibilità dei contenuti sul web ed un markup che conservi il più possibile un valore semantico (cioè che dica chiaramente cos'è e a cosa serve la parte di testo che contiene) il W3C ha introdotto alcuni marcatori che sono ancora poco usati dagli sviluppatori: fra essi, ABBR e ACRONYM definiscono, appunto, abbreviazioni o acronimi. Il loro utilizzo, in apparenza ovvio, presenta però più di qualche problema. In questo articolo vedremo come funzionano, quali problemi pongono, quale sia il supporto degli user agent e come sopperire alle loro eventuali carenze; infine ci occuperemo dei casi nei quali potrebbero addirittura creare significativi problemi di usabilità, che vanno dunque evitati con attenzione.

Le basi: cosa sono e come funzionano

ABBR e ACRONYM sono marcatori usati per definire abbreviazioni o acronimi. Attraverso l'attributo TITLE è possibile fornire l'espressione completa a cui si riferisce l'acronimo o l'abbreviazione. Secondo le specifiche di html 4.0, dove per la prima volta questi marcatori sono comparsi, il browser è incaricato di presentare, per lo più attraverso una piccola finestrella o un fumettino che compare quando il mouse passa sopra all'elemento, il testo contenuto nel TITLE. Dunque la sintassi corretta si presenta in questo modo:

<abbr title="confronta">cfr.</abbr>
<acronym title="Rapid Eye Movement">REM</acronym>

In teoria, una volta imparato questo, si è pronti per lanciarsi nel promettente mondo delle abbreviazioni e degli acronimi. I problemi però iniziano quasi subito: precisamente, non appena tentiamo di decidere cosa sia un acronimo e cosa non lo sia.

Secondo una definizione parafrasata dal dizionario, un acronimo è una sigla formata dalle iniziali delle parole che compongono un'espressione: WCAG è dunque un acronimo, quando si riferisce alle iniziali di Web Content Accessibility Guidelines. Anche CSS dovrebbe, secondo la definizione, essere un acronimo: sta per Cascading Style Sheet (fogli di stile a cascata). Cambiando settore, in ambito medico TAC è l'acronimo di Tomografia Assiale Computerizzata; sempre dall'ambito medico (o da quello musicale, a seconda delle vostre attitudini...) è tratto l'esempio di cui sopra (REM: Rapid Eye Movement).

Un'abbreviazione è invece qualunque riduzione di una parola o di una frase per mezzo di un'altra forma convenzionale: solitamente una sigla, una stringa di parole. Ad es., ecc., ad lib., cfr., sono tutte forme che in italiano sono abbreviazioni di espressioni più lunghe: ad esempio, eccetera, ad libitum, confronta.

L'acronimo non deve necessariamente essere una parola pronunciabile (CSS si legge "Ci-esse-esse"), né legale. Ovvero non deve rispettare le regole della fonetica di una certa lingua. In ogni lingua alcune sequenze di lettere sono parole "legali" e altre no. In italiano capiamo tutti che "cogomolo" è una parola legale: anche se non esiste potrebbe esistere, perché rispetta le regole fonetiche dell'italiano, mentre cgmfhloprv non lo è, perché non le rispetta.

In alcune lingue (per esempio nell'inglese) si stabilisce che un'abbreviazione - diversamente da un acronimo - può accettare prefissi e suffissi, e può dar vita a neologismi (HTMLl-er, per HTML-ista) a differenza dell'acronimo. In diverse lingue queste regole cambiano, e può diventare molto difficile stabilire se una parola è un acronimo o un'abbreviazione. Una scuola di pensiero sostiene che HTML o XML sono acronimi, mentre un'altra sostiene che siano abbreviazioni - forse solo perché è possibile usarle con una desinenza: HTMLer per HTMLista, appunto. Nella nostra lingua tale distinzione non pare appropriata.
Il W3C non fa dal canto suo molto per dirimere la questione. Considera HTML un'abbreviazione, ma senza fare chiarezza nelle definizioni.

Siccome c'è poca speranza di risolvere definitivamente la questione, e d'altra parte non ha molto senso coinvolgere gli sviluppatori in dispute degne degli accademici della Crusca, potrebbe non essere male poter disporre di un marcatore unico che indichi genericamente delle sigle: sia un acronimo che un'abbreviazione sono infatti sigle, espressioni sintetiche, per cui tale ipotetico marcatore potrebbe andar bene per tutti questi tipi di contenuti. Ma al momento è improbabile che questo si verifichi: quindi per la lingua italiana è bene attenersi al concetto che un acronimo è una parola formata dalle iniziali di altre parole, e le abbreviazioni tutto il resto. Ma senza scandalizzarsi se qualcuno usa ABBR per marcare HTML...

Ricordati che esistono i browser...

Naturalmente questo riguarda gli autori di pagine. E i browser? Non si comportano certo meglio.
In assenza di un marcatore adeguato o di un criterio risolutore, Microsoft ha pensato bene di tagliare la testa al toro e di non supportare affatto ABBR sui suoi browser (dunque su Explorer, proprio il più diffuso). Il che rende ancora più problematico l'uso corretto di questi marcatori, dato che, nel dubbio, è comunque preferibile usare ABBR anche al posto di ACRONYM, che viceversa: infatti un acronimo è pur sempre un caso particolare di abbreviazione, mentre non è vero il contrario.

Un altro problema riguarda la capacità dei lettori vocali di leggere correttamente la sigla. Infatti un acronimo potrebbe essere pronunciato da questi software in due diversi modi:

  1. come una sequenza di lettere (Ci-esse-esse, acca-ti-emme-elle)
  2. come una parola dotata di senso (NATO, TAC, REM).

Come decidere, di volta in volta? Lo stesso w3c riconosce che la pronuncia di un acronimo è spesso idiosincratica, cioè in alcuni casi avviene lettera per lettera, in altri come parola intera. Per semplificare la vita agli sviluppatori (anche se suona più come una presa in giro...) è stata dunque introdotta una specifica proprietà CSS2 per gli user agent appartenenti ai media aural (in pratica per i lettori vocali, non per i browser visuali). La proprietà è speak, e può assumere il valore normal, nel caso la parola venga letta come parola, e spell-out nel caso del lettera per lettera:

ABBR.parola, ACRONYM.parola {speak: normal;}
ABBR.sigla, ACRONYM.sigla {speak: spell-out;}

(NB: Speak può assumere anche i valori none e inherit, ma non è questo il luogo per addentrarsi in dettagli).

Assegnando le classi opportune ai diversi ABBR e ACRONYM nel testo, è possibile accertarsi che vengano letti nella maniera appropriata. Questo se i dispositivi di lettura supportassero questi marcatori, e queste specifiche di stile!

Sfortunatamente, infatti, anche i browser vocali o i lettori di schermo più diffusi hanno uno scarso o nullo supporto di questi standard... Jaws fino alla versione 4.02 non supporta nessuno dei due marcatori, né lo fa Home Page Reader. Non abbiamo provato l'ultima versione di Jaws, la 4.5, ma le note tecniche non menzionano tale supporto fra le nuove feature.

Tutto inutile, dunque? No: usare appropriatamente questi ABBR e ACRONYM aiuta sicuramente la comprensione dei testi agli utenti che utilizzano i browser visuali, dunque è sicuramente una comodità in più, ma come sempre è meglio non farsi troppe illusioni: il fatto che aiuti realmente chi ha problemi di accessibilità, è più che altro una buona intenzione. Diventa insomma più un'attenzione di usabilità, che di accessibilità, anche se le WCAG 1.0 prescrivono di usare il markup in maniera appropriata - e dunque per rispettarle bisogna usarli.

Parlando di usabilità, diventano tuttava cruciali altre considerazioni, non menzionate né previste esplicitamente nelle WCAG 1.0, ma non per questo meno vitali per i vostri utenti.

Usabilità: rendere percepibile e comprensibile

Ammesso e non concesso che riusciamo a districarci nella selva di decisioni che precedono l'uso di questi marcatori, ci si pone un altro problema. Infatti se la presenza di un elemento ABBR o ACRONYM non viene segnalato in qualche modo al lettore, come fa costui a sapere che posizionandocisi sopra potrà vedere la finestrella con l'estensione della sigla?

Il browser Mozilla ha risolto autonomamente la questione segnalando gli elementi con un piccolo bordo inferiore, dello stesso colore del testo. Purtroppo Explorer, al contrario, non solo non riconosce ABBR, ma non fa nulla di default per segnalare ACRONYM: il testo viene presentato come testo normale.

Sta emergendo così l'uso fra gli sviluppatori di definire attraverso i fogli di stile una proprietà che, ispirandosi almeno in parte al comportamento di Mozilla, stabilisca una regola di visualizzazione, nella speranza che assurga il prima possibile allo status di convenzione, e che magari venga implementata anche da Explorer e dagli altri browser.

ABBR, ACRONYM {border-bottom: 1px dotted black;}

Questa dichiarazione crea un bordo inferiore punteggiato (usando dashed invece che dotted, si crea un bordo tratteggiato, comunque accettabile, anche perché explorer, solo per dimensioni di 1px, tratta dotted esattamente come dashed...). L'aspetto è molto diverso da un link, ed è importante perché le parole usate come acronimi o abbreviazioni non devono indurre in errore l'utente spingendolo a cliccare. Ecco perché 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 come nei link. Anche la forma che si usa far assumere al cursore quando ci si posiziona sull'elemento (non la manina, ma un punto interrogativo) allontana l'idea di una 'zona cliccabile':

ABBR, ACRONYM {border-bottom: 1px dotted black; cursor: help;}

Queste convenzioni sono poco praticate, ma qualora vogliate usare questi marcatori nei vostri siti, è bene mantenerle: solo con un'ampia coerenza fra i siti gli utenti potranno, poco alla volta, imparare a riconoscere a colpo d'occhio un'abbreviazione o un acronimo e abituarsi al loro funzionamento. Se, al contrario, non definite alcuna specifica di stile per ABBR e ACRONYM, i vostri utenti non ne potranno trarre alcun beneficio.

Possibili soluzioni: superare i limiti di Explorer

Poiché ABBR non viene supportato da Explorer, ci si può trovar davanti due strade:

la prima è ignorare la cosa, e usare il tag correttamente, in attesa che le versioni future lo supportino.
La seconda è usare un trucchetto: inserire uno SPAN dentro l'elemento ABBR, e definire lo stile di quello span allo stesso modo.

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

e nel CSS:

ABBR, ACRONYM, SPAN.abbreviazione {border-bottom: 1px dotted black;
cursor: help;}

La soluzione è ridondante, sporca il codice con marcatori inutili, e non la raccomandiamo, dato che la questione non è di quelle che fanno perdere le notti ai vostri utenti. Ma è un'altra buona occasione per sottolineare come vivremmo tutti molto meglio se i browser fossero coerenti nel supporto degli standard web.

Mal di testa? Per vostra fortuna le WCAG 1.0 suggeriscono di usare questi marcatori solo la prima volta che usate l'espressione in una pagina. D'altra parte, per evitare di porsi continuamente la questione dell'uso corretto di acronimi e abbreviazioni, è bene stilare una guida editoriale e di stile per il vostro sito, che tenga conto delle convenzioni diffuse, e che vi sia di supporto per le scelte future. In questa guida di stile, è bene però considerare almeno un caso in cui l'uso di abbreviazioni e acronimi è assolutamente sconsigliato: per le voci di menu.

Cosa non fare: menu e voci di navigazione

Anche se rispettiamo le convenzioni di formattazione, acronimi e abbreviazioni non sono adatti a essere usati come voci nei menu di navigazione per almeno una semplice ragione: sono puro ostrogoto per chi non è già un esperto della materia.

Il che rende il menu semplicemente incomprensibile: le voci non riescono a predire all'utente quale sarà la destinazione della pagina, condizione indispensabile di ogni buon link. Certo, l'utente può posizionarsi sulla voce di menu per far comparire un fumetto esplicativo, ma è un'azione ulteriore: non è detto che l'utente sappia della convenzione, né che comunque lo faccia. Preferisce esplorare visivamente la pagina, e si aspetta che ciò che riguarda la navigazione sia comprensibile senza ulteriori sforzi.

Anche se lo facesse, si porrebbe il problema di quale informazione presentare, ovvero quale attributo title preferire: quello dell'elemento A o quello dell'elemento ABBR (o ACRONYM)? In caso di presenza di entrambi i title, Explorer privilegia quello dell'elemento più interno:in ogni caso una delle due informazioni non viene presentata.

Infine, anche qualora utilizzassimo una sigla molto conosciuta, un menu composto dalla sola sigla (abbreviazione od acronimo che sia) non ci direbbe comunque cosa troveremmo nella pagina di destinazione: una spiegazione della sigla? Una sezione che ci parli dell'argomento? Specifiche tecniche? O che altro? Dovremmo affidarci a dei title particolarmente esplicativi, ma naturalmente è molto meglio se la destinazione si capisce a partire dalla sola lettura del link. La conclusione è una sola: una semplice sigla (abbreviazione o acronimo) non è una buona label di navigazione.

C'è un'eccezione a questa regola: le sigle e gli acronimi possono ragionevolmente essere usate come voci di menu, previe opportune verifiche, esclusivamente in siti molto targetizzati e con utenza molto specialistica, come alcune intranet o come i siti di supporto agli help-desk telefonici, dove operatori esperti riconoscono certamente il significato di quelle espressioni, e, anzi, esse aiutano la sintesi e l'efficacia nella ricerca di informazioni. In ogni caso questi elementi non devono essere usati come voci di navigazione quando il sito intende rivolgersi ad un'utenza ampia, e abbia scopi comunicativi o divulgativi al di fuori di una cerchia specialistica di utenti controllati.

Usabilità, accessibilità e limiti delle linee guida

Ci sono alcune considerazioni da fare. Perseguire l'accessibilità è un obiettivo importante, che tutti i siti dovrebbero porsi, non solo quelli pubblici, che peraltro già raramente se lo pongono. Tuttavia, da questi esempi emerge che:

1. Seguire alla lettera le wcag1.0, ovvero le raccomandazioni del w3c per l'accessibilità dei contenuti web, non è sempre così facile, a causa di ambiguità e limiti delle linee guida stesse, ma anche di inadeguato supporto da parte degli user agent
2. seguirle non garantisce comunque l'usabilità delle vostre pagine. Se non vi ponete anche ulteriori problemi legati alla qualità dell'esperienza dell'utente sul vostro sito, o meglio ancora, se non testate le pagine con degli utenti reali, potreste produrre pagine valide e accessibili formalmente, ma che creano significativi ostacoli ad una corretta navigazione anche ad utenti normodotati.

Aggiungiamo, ad onor del vero, che le WCAG 1.0 prevedono fra le linee guida che la navigazione del sito debba essere semplice e intuitiva, e che il linguaggio debba essere comprensibile. Sfortunatamente, queste linee guida assomigliano di più a delle euristiche che a vere e proprie linee guida controllabili. A quali condizioni la navigazione è intuitiva e semplice? Quando il linguaggio si può considerare comprensibile? E chi deve preoccuparsi di verificarlo - e come? A queste domande le WCAG 1.0 non rispondono, e richiamano ad un semplice controllo umano, cioè non basato sul codice. Ecco perché i validatori automatici dell'accessibilità, pur essendo strumenti utili e addirittura indispensabili per sgravare lo sviluppatore da compiti altrimenti tediosissimi, non possono dar conto della qualità dell'esperienza dell'utente, e difficilmente possiamo immaginare dei valutatori automatici dell'usabilità. Proprio perché essa dipende spesso da scelte semantiche, logiche, scarsamente operazionalizzabili e variabili a seconda del contesto e del tipo di pubblico.

Questo ci riporta ad un limite tutto interno all'accessibilità, per come è attualmente normata dal WAI: quello di non prevedere per il momento forme di verifica sul campo del lavoro svolto, a differenza dell'usabilità che fa invece dei test con gli utenti l'arma migliore per la scelta di soluzioni di efficacia pratica e non solo teorica.

Articoli correlati:

torna su Torna su