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

Rispondi

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.