Diodati.org - Accessibilità e traduzioni dal W3C

Sponsor ufficiale di Diodati.org: Hosting a partire da 25 euro/anno | Domini a partire da 10,79 euro/anno | Server dedicati a partire da 120 euro/mese

Dopo aver analizzato i problemi di accessibilità del linguaggio usato nella comunicazione commerciale, quelli del linguaggio tecnico-scientifico ed infine quelli del linguaggio burocratico-amministrativo, è tempo ora di trarre le conclusioni: come fare a scrivere testi veramente accessibili?

Senza avere la pretesa di riscrivere i suggerimenti stilistici contenuti nelle tecniche associate alle WCAG 1.0, riteniamo utile fornire uno schema riassuntivo contenente non solo le principali raccomandazioni di carattere generale per l'accessibilità dei testi, ma alcuni consigli validi specificamente per gli autori italiani (in particolare il primo e l'ultimo dell'elenco).

• Scrivere per farsi capire. La prima e più importante raccomandazione, che coinvolge sia i contenuti testuali sia la forma in cui vengono espressi, è quella di scrivere per farsi capire, non scrivere per vendere un'immagine o un prodotto. Occorre mettersi nei panni degli utenti. Usare l'inglese al posto dell'italiano perché fa vendere di più, o usare termini astrusi e periodi interminabili per mostrare quanto si è colti, sono pratiche (e scopi) del tutto al di fuori dell'accessibilità.

• Usare il linguaggio più adatto all'argomento ed al pubblico di riferimento. Scrivere testi accessibili non vuol dire usare sempre e comunque un linguaggio adatto ad un bambino di prima elementare. Il lessico adoperato deve invece essere adeguato all'argomento, per cui, se si parla di fisica atomica, non sarà inaccessibile usare parole poco comuni come "protoni", "neutroni", "quark", "mesoni", ecc.

  Tuttavia, il lessico deve essere adeguato non solo all'oggetto, ma anche al pubblico di riferimento. Se ci si rivolge ad un pubblico ampio e non specializzato - come càpita ad un sito della Pubblica Amministrazione - conviene adoperare il lessico più semplice e di uso comune, purché sia in grado di comunicare correttamente il concetto che si vuole esprimere: meglio, perciò, se ci si rivolge alla gente comune, scrivere "perdita di sangue dal naso", laddove, in un sito rivolto ad un'utenza di medici, sarebbe del tutto accessibile scrivere "epistassi".

• Correggere gli errori grammaticali e sintattici. Usate a questo scopo i correttori automatici dei programmi di videoscrittura, ma, soprattutto, rileggete molte volte e con attenzione ciò che avete scritto: vi sono errori che sfuggono ai software, ma non agli uomini (e viceversa...). Avendone la possibilità, fate leggere i testi anche ad altre persone prima di pubblicarli: vi sono errori banali che hanno la perseveranza di non farsi notare anche dopo più letture consecutive della stessa persona. Considerate che i refusi possono pregiudicare seriamente la comprensione del testo per chi usa un sintetizzatore vocale.

• Definire i termini tecnici adoperati. Mentre in un forum di discussione frequentato solo da fisici è del tutto normale che si parli di "protoni", "mesoni", "raggi gamma", ecc. senza fornire definizione alcuna, viceversa in un sito divulgativo dedicato alla fisica, che pretenda di essere accessibile, parole come quelle sopra riportate dovrebbero essere definite la prima volta che sono utilizzate nel testo. Inoltre, è buona norma che la prima occorrenza in una pagina di un termine tecnico già definito altrove sia collegata alla definizione esistente.

  Tali suggerimenti valgono naturalmente non solo per la fisica, ma per qualsiasi disciplina scientifica o letteraria che disponga di un proprio lessico specialistico.

• Usare gli elementi strutturali di (X)HTML per evidenziare la struttura logica dei contenuti. L'uso di un appropriato codice di marcatura strutturale renderà più facile la comprensione dei contenuti per i lettori. Ciò implica:
  • usare gli elementi H1...H6 in modo da mostrare l'esatta gerarchia dei titoli presenti nel testo
  • usare differenti elementi P per differenti paragrafi di testo, invece che, per esempio, un unico elemento P intervallato da elementi BR per generare le dovute interruzioni di riga
  • usare BLOCKQUOTE e Q per le citazioni
  • usare UL ed OL per marcare degli elenchi di dati puntati o numerati
  • usare TABLE ed i suoi sottoelementi per strutturare opportunamente dati di natura tabellare
  • usare DL, DT e DD per marcare elenchi di definizioni e DFN per marcare definizioni isolate
  • usare CODE per specificare frammenti di codice di programmazione

• Fornire la forma estesa di abbreviazioni ed acronimi. Càpita spessissimo sul Web di trovare pagine stracolme di sigle di significato spesso esoterico, che il lettore non conosce e che gli rendono perciò oscura la comprensione del testo. Per evitare questo inconveniente, e favorire dunque l'accessibilità, è buona norma fornire in ciascuna pagina la forma estesa di tutte le sigle e le abbreviazioni utilizzate. Lo si può fare nel testo visibile, affiancando alla sigla la sua forma estesa, o a livello di codice, usando gli appositi elementi ABBR e ACRONYM, da usarsi rispettivamente per le abbreviazioni (ad es. "Sig.") e per gli acronimi (ad es. "FIAT").

  Per rendere visibile la presenza nel codice della pagina della forma estesa di una sigla, si è diffusa recentemente l'abitudine, da parte degli sviluppatori che si occupano di accessibilità, di marcare la sigla tramite CSS, in modo che appaia una riga tratteggiata sotto di essa e che, al passaggio del mouse, il cursore si trasformi in un punto interrogativo. Questo accorgimento serve per chi usa Internet Explorer. Mozilla, Netscape e Opera mostrano infatti nativamente all'utente la sottolineatura delle sigle, se è presente nel codice di marcatura la loro forma estesa.

  Secondo il punto di controllo 4.2 delle WCAG 1.0, non tutte le occorrenze di una medesima sigla all'interno di una pagina devono essere marcate con ABBR o ACRONYM, bensì solo la prima occorrenza. In pagine molto lunghe e complesse, suggeriamo tuttavia di marcare con ABBR o ACRONYM, a seconda della necessità, più occorrenze della medesima sigla, nel caso che le sue ripetizioni appaiano isolate nel testo e molto distanziate tra loro.

• Segnalare i cambi di lingua. Chi usa un sintetizzatore vocale può non comprendere una parola inglese presente in una pagina, se gli viene letta all'italiana (è il caso ad es. di termini come "firewall" e "policy").

  Per consentire alle tecnologie assistive di leggere ciascuna parola in modo comprensibile, cioè secondo le regole di pronuncia della lingua a cui appartiene, è opportuno segnalare nel codice di marcatura, per mezzo dell'apposito attributo "lang" (o "xml:lang" se si usa XHTML 1.1), i cambi di lingua presenti nel testo.

  Poiché allo stadio attuale di sviluppo delle tecnologie assistive, il cambio di lingua "al volo" può produrre rallentamenti notevoli nella lettura della pagina, consigliamo agli autori - discostandoci in questo parzialmente dal dettato delle WCAG 1.0 - di evitare di marcare come cambi di lingua quelle parole inglesi che o sono state assorbite dalla lingua italiana o, anche se pronunciate all'italiana dal sintetizzatore vocale, rimarrebbero ugualmente comprensibili per l'ascoltatore ("trend", "big", "font", ecc.).

• Ridurre al minimo l'uso di parole non italiane. Se volete scrivere testi accessibili, evitate di utilizzare una parola straniera ogni volta che sia disponibile un accettabile equivalente italiano. Questo accorgimento non solo favorirà chi ha una cultura medio-bassa e chi ha problemi di attenzione e di lettura, ma soprattutto chi utilizza un sintetizzatore vocale: riducendo l'uso dei termini stranieri si riduce infatti la necessità di segnalare i cambi di lingua nel testo. Questi presentano un duplice inconveniente:
  • se la tecnologia assistiva adoperata li supporta, può esserci una lunga attesa dovuta alla necessità da parte del programma di caricare il motore di sintesi adatto alla nuova lingua e ritornare poi, subito dopo, alla pronuncia italiana

  • se non li supporta, leggerà comunque le parole straniere all'italiana, rischiando di renderle del tutto incomprensibili per l'ascoltatore.

    Una parziale soluzione al problema della lettura delle numerose parole inglesi che gli autori italiani sono soliti inserire nei propri testi scritti, potrebbe essere quella di produrre dei browser vocali e degli screen reader dotati di dizionari specializzati, contenenti la pronuncia italianizzata di parole inglesi entrate nell'uso comune, quali "chat", "bug", "copyright", "mouse", "fast food", ecc. ecc.