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

Siamo giunti ormai alla fine di questo lungo viaggio attraverso l'accessibilità. Tutta la guida è nata ed è cresciuta intorno ad un'idea centrale: guidare il lettore alla scoperta dei concetti che stanno alla base della realizzazione di siti ad elevata accessibilità. Non ci interessava, infatti, ripercorrere pedissequamente le WCAG 1.0, mostrando in successione le singole raccomandazioni ed i tanti esempi possibili di buona e cattiva applicazione. Ci interessava piuttosto aiutare il lettore ad impadronirsi di due tipi di sapere, indispensabili per padroneggiare proficuamente questa materia:

• una conoscenza teorica di base su cosa è l'accessibilità e su chi ne sono i beneficiari;
• una serie di conoscenze tecniche di valore pratico, per partire fin da subito con lo sviluppo di pagine web ad elevata accessibilità

Ma perché abbiamo puntato su un'accessibilità che abbiamo definito "elevata" e non sull'accessibilità punto e basta?

Perché ci interessa instillare nei lettori di questa guida l'idea che si possa svolgere l'attività professionale di sviluppare siti web in un modo completamente nuovo - e molto più accessibile nei risultati - rispetto al sistema utilizzato negli anni scorsi e tuttora largamente usato. Il sistema da superare è quello, dilettantesco, di imparare ad assemblare pagine web servendosi esclusivamente degli appositi software di tipo visuale in commercio, senza accoppiare a tale pratica lo studio dei fondamenti di questa costruzione, che sono - riducendoli all'essenziale - i linguaggi HTML, XHTML, CSS2 e le specifiche W3C sull'accessibilità.

L'accessibilità di base deve occuparsi di turare alla meglio le falle aperte dal cattivo sviluppo. Può fare qualche rattoppo, non miracoli, limitandosi a:

• inserire i testi alternativi mancanti
• provare a mettere qualche elemento NOSCRIPT qua e là
• avvertire il lettore, tramite un attributo "title", che una certa pagina si aprirà in una nuova finestra del browser
• cercare di rendere una struttura a frame un po' più navigabile, dando dei titoli sensati ai frame o creando una minima alternativa di navigazione con un elemento NOFRAMES
• provare a ridurre un po' la massa del codice presentazionale mischiato al contenuto, trasferendo una parte della presentazione visuale ad un foglio di stile esterno
• correggere gli errori di codice in modo che le pagine passino la validazione
• creare qualche pagina alternativa a quelle contenenti animazioni Flash non accessibili o applet java non navigabili da tastiera
• ecc. ecc.

Quella che abbiamo definito elevata accessibilità è invece il risultato quasi naturale del buono sviluppo. Qui non si tratta più di mettere rattoppi, ma piuttosto di valorizzare e incrementare l'accessibilità già connaturata ad una progettazione fondata sul rispetto dei linguaggi standard.

La seconda parte di questa guida è stata pensata proprio per spiegare ai lettori i fondamenti di questo nuovo modo di progettare per il Web, basato sul rispetto degli standard e delle specifiche di accessibilità. Non si propone di insegnare come "rattoppare" pagine nate male, ma di spiegare come far "nascere bene" nuove pagine e siti. Tali fondamenti di progettazione sono stati suddivisi in quattro sezioni, che sono da considerarsi come altrettanti pilastri di quello che abbiamo chiamato "buon sviluppo".

• la separazione della presentazione di un documento dal suo contenuto e l'uso accessibile del colore
• la valorizzazione della struttura di un documento
• le regole per scrivere testi ad elevata accessibilità
• la validazione del codice e la valutazione dell'accessibilità

Siamo consapevoli di non aver trattato tutti gli argomenti tecnici che rientrano nel campo di applicazione delle raccomandazioni di accessibilità: non abbiamo parlato, per esempio, dei sistemi di sottotitolazione per rendere accessibili i contenuti multimediali; non abbiamo parlato dei collegamenti ipertestuali e del modo di renderne accessibili i testi; abbiamo accennato soltanto di sfuggita all'uso dei tasti di accesso rapido ("accesskey"); non abbiamo parlato di applet java e animazioni in Flash; l'uso del javascript è stato considerato solo incidentalmente, esaminando i sistemi per consentire all'utente di personalizzare l'interfaccia di navigazione. Riteniamo tuttavia che queste mancanze non pregiudichino la comprensione, da parte del lettore, degli importanti concetti generali che la guida si propone di divulgare.

A conclusione del lungo cammino compiuto, riassumiamo in un elenco schematico i suggerimenti principali per la realizzazione di una pagina (o di un sito) "ad elevata accessibilità", avendo la fondata speranza che i singoli punti dell'elenco risultino a questo punto chiari e comprensibili - non solo nel significato, ma nella loro necessità - per i lettori che hanno avuto la pazienza di leggere fino a qui.

• Separate la presentazione di un documento dal suo contenuto: ciò significa che, da un lato, occorre evitare di inserire nel codice (X)HTML vincoli di presentazione, dall'altro occorre usare i CSS per definire la formattazione del documento e la sua eventuale presentazione per altri media (stampa, sintetizzatori vocali, telescriventi, computer palmari, Web TV, ecc.)
• Usate la DTD strict di XHTML 1.0 o, in alternativa, la DTD di XHTML 1.1: sono le più adeguate a raggiungere lo scopo di separare la presentazione dal contenuto
• Non affidate nessuna informazione esclusivamente all'uso del colore
• Evidenziate la struttura logica dei contenuti testuali, usando nel modo più appropriato gli appositi elementi ed attributi strutturali di (X)HTML
• Realizzate moduli accessibili, utilizzando gli appositi elementi ed attributi - FIELDSET, LABEL, ecc. - ed i CSS per rendere i vari campi più visibili nella pagina (ed eventualmente ingrandibili a discrezione dell'utente)
• Rendete accessibili le tabelle di dati, utilizzando gli appositi elementi ed attributi strutturali previsti a partire da HTML 4: CAPTION, TH, COL, COLGROUP, summary, scope, headers, id, ecc.
• Sostituite le tabelle usate a scopo di impaginazione con soluzioni basate sui CSS. Se decidete di utilizzare comunque delle tabelle di impaginazione, evitate possibilmente di annidare più tabelle una nell'altra e, soprattutto, di formattarne le celle per mezzo di elementi e attributi presentazionali di (X)HTML. Per la loro formattazione usate piuttosto i CSS e, soprattutto, assicuratevi che il contenuto di ciascuna tabella di impaginazione venga linearizzato correttamente, se letto in modalità non grafica
• Scrivete testi alternativi che svolgano una funzione equivalente a quella del contenuto non testuale che sostituiscono.
• Scrivete testi accessibili, in cui sia esaltata la semplicità, la correttezza e l'adeguatezza del linguaggio, e siano allo stesso tempo evitate le deformazioni e le incomprensibilità proprie dello stile pubblicitario, dello stile tecnicistico e dello stile burocratico.
• Non utilizzate frame. Esistono altri modi più accessibili di costruire un'interfaccia di navigazione
• Realizzate pagine i cui contenuti rimangano accessibili nelle più disparate condizioni d'uso, piuttosto che pagine che si vedano allo stesso modo su tutti i principali browser grafici: liberatevi, cioè, dal "pregiudizio della stampa"
• Scrivete pagine basate su codice (X)HTML e CSS valido
• Usate strumenti automatici per scoprire gli errori di accessibilità legati al codice
• Usate la revisione umana per verificare l'accessibilità di tutti gli elementi della pagina non controllabili in automatico (proprietà e correttezza dei testi, comprensibilità dei meccanismi di navigazione, contrasto primo piano/sfondo, ecc.)
• Ponetevi come obiettivo il raggiungimento di un'accessibilità reale, verificata per mezzo di test e riscontri con individui umani, piuttosto che la sterile esposizione di bollini di conformità.