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.

Potrebbero interessarti anche i seguenti articoli

Condividi:

Informazioni sull'autore

Maurizio Boscarol
Maurizio Boscarol
Psicologo e informatico, Maurizio Boscarol si laurea in comprensione dei testi. Dopo una decennale esperienza nel campo della comunicazione tradizionale si dedica al web, dove dal 2000 idea e gestisce www.usabile.it, il primo sito italiano di divulgazione e consulenza sull'usabilità. Come libero professionista si dedica alla consulenza sui temi dell'accessibilità, dell'usabilità e degli standard web per web agency italiane, collaborando a importanti progetti nazionali. Si occupa di formazione sugli stessi argomenti per enti pubblici e privati. La sua personale convinzione è che usabilità e accessibilità non siano in conflitto con la comunicazione e il design, e tenta di dimostrarlo nel suo lavoro, nei suoi articoli e nelle sue consulenze.

Commenti

Nessun commento

    Rispondi

    Link e informazioni