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

Ci sono dei casi in cui è giustificato scrivere termini in inglese all'interno di testi in italiano? Sì: quando le parole o le espressioni inglesi utilizzate sono dei nomi propri, quando sono davvero di uso comune e quando non esistono equivalenti in italiano altrettanto noti e diffusi. Un uso accessibile della terminologia inglese richiede che si specifichi nel codice il cambio di lingua rispetto alla lingua principale del documento (tramite l'attributo " lang" per HTML 4 e XHTML 1.0 e tramite l'attributo "xml:lang" per XHTML 1.1) e che si definisca il termine adoperato, straniero o italiano che sia, se è poco comune o se fa parte di un gergo specialistico.

Un caso particolare di stile di scrittura particolarmente ricco di termini in inglese e di sigle è il gergo degli informatici. Basta dare uno sguardo ad un qualsiasi articolo on line che tratti di software o di hardware per cadere in una spirale di parole inglesi degne di una setta iniziatica. Molto spesso non è possibile sostituire questi termini con equivalenti italiani, non perché la nostra lingua non consentirebbe di creare appositi neologismi (i francesi per esempio ne creano di continuo), ma perché coniare all'improvviso nuove parole per termini inglesi già entrati da tempo nell'uso, anche se solo specialistico, non migliorerebbe l'accessibilità dei testi... almeno non nel breve periodo.

Ecco comunque alcuni modi per rendere comunque più accessibili questi testi a lettori italiani:

• segnalare, come già spiegato, i cambi di lingua
• usare a profusione ABBR e ACRONYM per mettere ordine nell'immane babele di sigle esistenti
• accludere ad articoli e notizie, o al sito nel suo insieme, un esauriente glossario contenente accurate definizioni in italiano dei termini specialistici adoperati.

Facciamo un esempio pratico. Dal sito di PC Professionale, versione per Internet di una delle più note riviste italiane di informatica, estraiamo un paragrafo da un articolo di Guido Sintoni intitolato " Buffer Overflow e replay attack in Kerio" (già il titolo è tutto un programma...). Nella versione in Rete dell'articolo non è presente alcun ausilio di accessibilità: nessuna segnalazione dei cambi di lingua né tantomeno un glossario dei numerosi termini inglesi adoperati.

Potremmo rendere un po' più accessibile questo paragrafo cominciando a segnalare i cambi di lingua nel codice di marcatura.

<p>Il processo di autenticazione è anche soggetto a un <span lang="en">buffer overflow</span>: quando l'amministratore si connette al <span lang="en">firewall</span>, avviene un <span lang="en">handshake</span> per stabilire una sessione cifrata. Il quarto pacchetto del <span lang="en">handshake</span> (il primo inviato dall'amministratore) contiene 4 <span lang="en">byte</span>; non esistendo lato <span lang="en">firewall</span> un controllo di lunghezza dei dati ricevuti, per l'attaccante è possibile costruire una sequenza di pacchetti in modo tale da provocare un <span lang="en">overflow</span> dello stack. Al momento in cui scriviamo, Kerio è stata contattata da CORE, e non ha ancora rilasciato una soluzione. Per prevenire il replay attack è consigliabile disabilitare la funzione di amministrazione remota.</p>

Notate che per alcuni dei termini inglesi evidenziati nel testo non abbiamo segnalato il cambio di lingua. Ciò in realtà è contrario a quanto suggeriscono le WCAG 1.0, che raccomandano di segnalare i cambi di lingua senza specificare eccezioni. Tuttavia riteniamo che, nel caso di parole straniere isolate, la segnalazione del cambio di lingua tramite l'attributo "lang" possa essere evitata, se la lettura "all'italiana" della parola straniera da parte di un sintetizzatore vocale rimane comunque comprensibile per l'ascoltatore. Tornando al paragrafo che stiamo analizzando, uno screen reader impostato sull'italiano leggerebbe in modo sicuramente poco comprensibile parole come "handshake" e "firewall": ecco perché sono state associate ad appositi attributi lang="en". Invece parole come "stack" e "replay attack" dovrebbero rimanere comprensibili per l'ascoltatore anche se lette all'italiana. Abbiamo preferito perciò non appesantire il codice aggiungendo ulteriori elementi SPAN.

Dal punto di vista dei contenuti l'accessibilità di questo paragrafo potrebbe essere poi migliorata inserendo alla fine un piccolo glossario come il seguente, strutturato in HTML come un elenco di definizioni:

<dl>
<dt lang="en">Buffer overflow</dt>
<dd>sovraccarico di un'area di memoria del computer, dovuto al tentativo di immagazzinare una stringa più grande dello spazio utile a disposizione.</dd>
<dt>Stack</dt>
<dd>un'area di memoria adibita a contenere dei dati impilati in un ordine preciso, ai quali è possibile accedere per mezzo di un apposito puntatore che tiene traccia della loro posizione.</dd>
<dt lang="en">Handshake</dt>
<dd>processo attraverso il quale due computer, tramite software o hardware, stabiliscono le regole comuni, ovvero la velocità, i protocolli di compressione, di criptazione, di controllo degli errori, ecc... </dd>
<dt lang="en">Firewall</dt>
<dd>insieme di software/hardware usato per filtrare i dati in scambio fra reti diverse, al fine di proteggere un server da attacchi pervenuti via rete locale o via Internet. </dd>
<dt>Replay attack</dt>
<dd>consiste nell'immissione in rete da parte dell'intruso di un pacchetto autentico precedentemente intercettato. </dd>
</dl>

E per concludere con il gergo dell'informatica, ecco un esempio di proliferazione di sigle, faticosamente mantenuto nei confini dell'accessibilità attraverso una profusione di elementi ACRONYM e ABBR. Il testo originale, benché scritto in modo molto chiaro in relazione all'argomento esposto, non presenta nel codice né la forma estesa di acronimi e abbreviazioni né segnalazioni dei cambi di lingua.

<p>Con <acronym lang="en" title="Host Identity Payload">HIP</acronym> si propone di inserire un nuovo spazio di nomi in Internet, chiamato <em lang="en">Host Identity</em> (HI), che permetterebbe di disaccoppiare il <em lang="en">routing</em> (ovvero il livello 3, dove si continuerebbe ad usare gli indirizzi <acronym lang="en" title="Internet Protocol">IP</acronym>) dai livelli superiori (dal trasporto all'applicazione, dove si userebbe la <em lang="en">host identity</em>). Questo nuovo spazio di nomi avrebbe caratteristiche crittografiche (trattandosi essenzialmente di chiavi pubbliche) e quindi potrebbe essere utilizzato per autenticare gli <em lang="en">host</em> con <abbr lang="en" title="IP Security Protocol">IPsec</abbr>. Uno stesso <em lang="en">host</em> può avere più <acronym lang="en" title="Host Identity">HI</acronym>, alcune pubbliche (ovvero registrate nel <acronym lang="en" title="Domain Name System">DNS</acronym>) e altre anonime; può inoltre "autocertificare" la propria identità oppure utilizzare un meccanismo per garantirla, quale <abbr title="Domain Name System Security">DNSSEC</abbr>, <acronym lang="en" title="Pretty Good Privacy">PGP</acronym>, o i certificati X.509. Dato che la HI può avere formato e lunghezza variabili, è previsto l'uso di un <em lang="en">Host Identity Tag</em> (HIT) di 128 bit, costituito essenzialmente da un <em lang="en">hash</em> della HI e anch'esso immagazzinato nel DNS (se pubblico). La HI non deve mai essere espressamente utilizzata dai protocolli di rete: viene esclusivamente immagazzinata (eventualmente) in server DNS o <acronym lang="en" title="Lightweight Directory Access Protocol">LDAP</acronym> e passata durante l'<em lang="en">handshake</em> di HIP, mentre tutti i protocolli utilizzano esclusivamente lo HIT, come rappresentazione della HI.</p>

Ci sono alcune cose da notare. In primo luogo gli elementi ABBR e ACRONYM non sono usati per quelle sigle il cui significato è già definito all'interno del testo visibile del paragrafo, come nei casi delle sigle HI e HIT: è inutile infatti appesantire il codice, quando la funzione chiarificatrice di ABBR e ACRONYM risulta già svolta da una spiegazione esplicita presente nel testo.

Notate inoltre che quando una stessa sigla ricorre più volte, viene definita da un elemento ABBR o ACRONYM solo la prima volta che appare nel testo: è il caso, nel nostro paragrafo di esempio, della sigla DNS. Ciò obbedisce al suggerimento contenuto nel punto di controllo 4.2 delle WCAG 1.0.

Segnaliamo infine l'uso di "lang" all'interno dell'elemento EM, invece che all'interno di SPAN. E' una consuetudine della carta stampata, accettabile anche per il Web, di porre in rilievo i termini stranieri presenti nel testo. In stampa lo si fa generalmente tramite l'uso del corsivo. Noi lo abbiamo fatto tramite l'elemento strutturale EM, che pone enfasi sul testo da esso racchiuso. In più ci offre l'aggancio per segnalare il cambio di lingua per mezzo del solito attributo "lang", che altrimenti avrebbe richiesto, per essere inserito, l'uso di un apposito elemento SPAN.