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, una tesi di laurea scritta 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 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 livello3, dove si continuerebbe ad usare gli indirizzi
<acronym 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 title="IP Security Protocol"> IPsec
</abbr> .
Uno stesso
<em lang="en"> host
</em> può avere più
<acronym title="Host Identity"> HI
</acronym> , alcune pubbliche (ovvero registrate nel
<acronym 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 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 128bit, 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 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. È 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.
