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:
- come una sequenza di lettere (Ci-esse-esse, acca-ti-emme-elle)
- 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.