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

Come abbiamo detto, realizzare documenti costruiti su codice (X)HTML e CSS valido equivale ad aver piantato solide fondamenta su cui costruire una "casa" ad elevata accessibilità. Non basta ancora, però, perché un documento sia pienamente accessibile. Si possono, infatti, costruire pagine perfettamente aderenti alla sintassi di HTML e CSS, piene tuttavia di contenuti inaccessibili. Occorre quindi, per valutare il grado di accessibilità raggiunto, ricorrere a degli strumenti specifici.

In effetti la valutazione dell'accessibilità è una cosa tutt'altro che semplice e dà luogo a non pochi equivoci. Cominciamo ad esaminare che cosa suggeriscono le linee guida W3C a tal proposito.

L'Appendice A delle WCAG 1.0 è dedicata infatti proprio al tema della validazione, cioè della verifica di accessibilità. La raccomandazione generale rivolta agli autori di pagine web è la seguente:

Verificate l'accessibilità per mezzo di strumenti automatici e della revisione umana. I metodi automatici sono in genere rapidi e convenienti ma non possono identificare tutti i problemi di accessibilità. La revisione umana può aiutare a garantire la chiarezza del linguaggio e la semplicità della navigazione.

Questa raccomandazione è importante, perché pone l'accento su quello che è il rischio principale delle valutazioni di accessibilità affrettate, che nascono dalla mera esigenza economica di fare presto e di ritenere finito il lavoro con l'esposizione di qualche bollino di conformità: il rischio di affidarsi unicamente all'analisi di strumenti automatici.

Mentre i software possono valutare la correttezza del codice e la presenza di ausili per l'accessibilità, quali gli attributi "alt", "longdesc" e "summary" o gli elementi CAPTION e LABEL, non possono invece valutare che cosa viene scritto nei valori di quegli attributi e nei contenuti di quegli elementi. E' qui che la revisione umana svolge un ruolo essenziale. Per il momento c'è una regola che non ha eccezioni: nessun controllo automatico è in grado di valutare al 100% l'accessibilità di una pagina web.

Ma non è neppure una questione di percentuali, cioè di numeri, di quantità. E' piuttosto una questione di qualità: la qualità di un testo alternativo o di una definizione, per esempio, può essere valutata solo da un revisore umano. Solo un essere umano è in grado di dire se e come un certo testo alternativo o una certa definizione aiutano a comprendere i contenuti di una pagina, cioè a renderli più accessibili.

Ciò premesso, vediamo un po' più nel dettaglio con quali sistemi l'Appendice A delle WCAG 1.0 consiglia agli autori di verificare l'accessibilità delle proprie pagine web.

• I primi tre punti, dei dieci complessivi che compongono la lista dei suggerimenti, sono dedicati alla validazione del codice per mezzo di strumenti automatici: si suggerisce di controllare con tali sistemi la validità della sintassi HTML (o XML) e CSS, nonché le misure prese per favorire l'accessibilità, ma si avverte ancora una volta che nessun software è in grado di controllare cose come la significatività dei testi dei collegamenti o l'applicabilità dei testi alternativi.
• I quattro punti centrali (dal 4 al 7 compreso) suggeriscono verifiche di percepibilità dei contenuti per mezzo della vista e dell'udito nelle più disparate condizioni d'uso: con un browser testuale, con un emulatore di terminale, con differenti tipi di browser grafico, con browser vecchi e nuovi, con le immagini e senza immagini, con i suoni e senza i suoni, con il mouse e senza mouse, con il supporto per frame, linguaggi di script, fogli di stile e applet java disabilitato, con un browser vocale, con uno screen reader, con un ingranditore di schermo, con un monitor molto piccolo, ecc.
• Gli ultimi tre punti riguardano infine gli aspetti cognitivi dell'accessibilità. Ancora una volta si consiglia il ricorso a strumenti automatici: per esempio un correttore ortografico, per trovare ed eliminare i refusi dal testo, e un valutatore di leggibilità, cioè uno di quegli strumenti tipici dei programmi di videoscrittura, in grado di produrre valutazioni, basate su dizionari interni e calcoli statistici, relative al tipo di linguaggio adoperato in un testo (formale, colloquiale, burocratico, ecc.). Tuttavia, si consiglia anche esplicitamente di ricorrere al giudizio di revisori umani e in particolare di persone con disabilità: queste ultime, meglio di chiunque altro, potranno valutare se le misure prese per favorire l'accessibilità sono sufficienti oppure no.

Al termine di queste accurate valutazioni, gli autori possono esporre a loro discrezione, sulle pagine controllate, degli appositi bollini di conformità alle WCAG 1.0. Le relative istruzioni sono disponibili alla pagina http://www.w3.org/WAI/WCAG1-Conformance.html.en.

Figura 12 - Le tre icone di conformità alle linee guida WCAG 1.0, che gli autori possono esporre sulle pagine controllate, a seconda del livello di conformità che dichiarano di aver raggiunto

Quando capita di imbattersi in pagine che espongono tali bollini o - come si usa molto adesso per non "disturbare" la grafica - delle stringhe di testo di analogo significato (p.es. "WAI-AAA"), è bene ricordare che ciò rappresenta semplicemente una pretesa di conformità della pagina alle specifiche WCAG 1.0, ma in nessun modo un attestato ufficiale di accessibilità, che nessun ente o organizzazione è per il momento in grado di rilasciare.

Purtroppo questa chiara distinzione è spesso ignorata dai più: ciò si traduce in una sorta di truffa ai danni dell'utente, che ha bisogno di vera accessibilità, non di bollini. Infatti, molto più spesso di quanto non si creda, anche istituzioni pubbliche importanti espongono dichiarazioni di conformità al massimo livello di accessibilità (il livello tripla A), che basta una rapida analisi da parte di un esperto per dimostrare fasulle. Non sappiamo in questi comportamenti quanto vi sia di superficialità e quanto di dolo. Fatto sta che sarebbe di gran lunga preferibile che i gestori di siti si limitassero ad esporre solo dichiarazioni autenticamente e severamente controllate: la fiera dei bollini serve soltanto a gettare discredito sul tema dell'accessibilità, che è invece di fondamentale importanza non solo per i disabili, ma per chiunque tenga ad una vera democrazia dell'informazione e dei servizi in Rete.

Un altro strumento al servizio dei millantatori di accessibilità è Bobby, un noto software in grado di effettuare un'analisi automatica del codice di una pagina web, mettendo in luce - quando li trova - gli elementi che non soddisfano i requisiti richiesti dalle WCAG 1.0.

Questo software, se usato con intelligenza, è uno strumento sicuramente utile. Permette infatti di identificare con relativa facilità un gran numero di pecche di accessibilità a livello di codice. Il guaio è che sta diventando una sorta di valore commerciale in sé, per gli sviluppatori, ottenere la validazione da parte di Bobby (cioè l'apparire del suo bollino di conformità al termine dell'analisi effettuata sulla pagina), indipendentemente dai successivi controlli umani di accessibilità che Bobby stesso sollecita.

Nella figura 13 possiamo vedere, accanto all'icona "Bobby AAA approved", ottenuta al termine dell'analisi di una pagina web in cui Bobby non ha riscontrato errori, il testo che invita l'autore della pagina analizzata ad effettuare successivi controlli di tipo umano. Ecco cosa dice quel testo, tradotto in italiano:

Se i punti di priorità 1, 2 e 3 elencati più sotto non si applicano alla vostra pagina, ciò la qualifica allora come Bobby AAA approved e voi siete autorizzati ad usare l'icona Bobby AAA approved.

Figura 13 - Quando Bobby non trova errori di accessibilità nel codice di una pagina, invita l'autore ad effettuare una serie di controlli umani sugli elementi che il programma non è in grado di analizzare. Solo se la pagina supererà anche i successivi controlli umani, l'autore avrà diritto ad esporre il loghino "Bobby approved"

In teoria, dunque, si è autorizzati ad esporre l'icona solo dopo aver superato tutti i controlli umani suggeriti dal programma!

Poiché gli elementi che Bobby non può controllare sono importantissimi ai fini dell'accessibilità - per esempio la chiarezza del linguaggio adoperato e la validità dei testi alternativi - esporre l'icona "Bobby AAA Approved" senza aver effettuato adeguati controlli tramite revisori umani non ha alcun valore come dichiarazione di accessibilità. A nostro parere, i siti che espongono questo bollino (o una stringa testuale di significato equivalente), dovrebbero accludere un'esplicita dichiarazione che renda noti agli utenti quali e quanti controlli di revisione umana sono stati effettuati sulla pagina, e quando sono stati effettuati.

Invece pare che ciò che interessa i gestori di siti "accessibili" sia non tanto il raggiungimento di una vera accessibilità, quanto soprattutto l'esporre il maggior numero possibile di dichiarazioni di conformità: conformità alle specifiche HTML o XHTML, alle specifiche CSS, al livello tripla A delle WCAG 1.0, e poi il bollino Bobby AAA Approved e - incredibile a dirsi per siti italiani! - anche la conformità alle norme di accessibilità statunitensi che vanno sotto il nome di Section 508! Ci sarebbe da ridere - soprattutto per chi si dichiara conforme contemporaneamente alle WCAG 1.0 e alla Section 508 - se non ci fosse invece da piangere!

Per non lasciare il discorso sulle generali, portiamo un esempio concreto di dichiarazione non conforme alla realtà: la prima pagina del portale Spazio Europa della Regione Emilia-Romagna, tanto per fare un nome. Questa pagina dichiara, oltre alla conformità ad HTML 4.01, CSS 2.0, Bobby AAA e Bobby Section 508 (ci sarà qualche convenzione con gli Stati Uniti?), anche la conformità al livello tripla A delle WCAG 1.0, ed è quest'ultima dichiarazione che ci interessa.

Basta una scorsa anche superficiale al listato della pagina, per scoprire che né il codice di marcatura né i contenuti soddisfano tutti i punti di controllo delle WCAG 1.0, come sarebbe lecito attendersi da un documento che dichiara di essere conforme al livello tripla A delle WCAG 1.0. Ecco alcuni dei "difetti" riscontrati (in data 5/9/2003).

• Non esistono link per saltare il menu di navigazione e gli altri blocchi della pagina (cfr. il punto di controllo 13.6 delle WCAG 1.0)
• Non sempre la destinazione dei collegamenti è comprensibile per chi naviga senza immagini: p.es. i testi alternativi "[Logo Spazio Europa]" e "[Logo Europa facile]" non dicono molto circa le destinazioni dei collegamenti applicati alle relative immagini, che sono rispettivamente la home page stessa ed il sito Europa facile. Lo stesso problema si verifica per tutte le immagini usate come icone di navigazione e allo stesso tempo come link, nel menu di sinistra della pagina (cfr. il punto di controllo 13.1)
• Vi sono collegamenti che aprono una nuova finestra del browser, senza che l'utente venga avvertito della cosa (cfr. il punto di controllo 10.1)
• Nessuna delle sigle presenti nel contenuto testuale - "UE", "WTO", "OGM" - è chiarita per mezzo degli appositi elementi ABBR o ACRONYM (cfr. il punto di controllo 4.2)
• I titoli presenti nella pagina sono inseriti in celle di tabella e non evidenziati con un'adeguata marcatura strutturale, per es. per mezzo degli elementi H1...H6 (cfr. il punto di controllo 3.5)
• La presentazione visuale della pagina è affidata all'uso di tabelle di impaginazione ed elementi e attributi di presentazione: la seconda soluzione in particolare è disapprovata dalle linee guida W3C (cfr. i punti di controllo 3.3 e 11.2)
• L'attributo "summary" è utilizzato in modo erroneo, in quanto non spiega la struttura delle tabelle in cui è inserito (che sono tabelle di impaginazione), ma contiene testi superflui e poco indicativi per chi naviga in modalità non visuale

Inutile proseguire nell'analisi. Sarà chiaro per tutti i lettori che la pagina portata ad esempio dichiara una conformità fasulla al livello tripla A delle WCAG 1.0. Benché si debba riconoscere a onor del vero che è molto più accessibile di infinite altre pagine di siti pubblici, è lecito domandarsi: era proprio necessario dichiarare la tripla A?

Potremmo dimostrare numerosissimi altri casi analoghi a quello del portale Spazio Europa. Crediamo però che il concetto che vogliamo sostenere sia a questo punto sufficientemente chiaro: diffidate dei siti che abbondano di bollini e dichiarazioni di conformità! Il malcostume tutto italiano di vendere l'immagine al posto della sostanza, o nel migliore dei casi meno sostanza di quella dichiarata, trova nelle dichiarazioni di accessibilità uno strumento ideale.

Da parte nostra ci limitiamo, per quanto riguarda la validazione di accessibilità delle pagine web, a poche semplici raccomandazioni:

1. validate il codice (X)HTML in modo che sia privo di errori
2. validate il codice CSS in modo che sia privo di errori e di avvertimenti
3. fate analizzare il codice della pagina da strumenti automatici per l'accessibilità, quali HTML Tidy o Bobby (meglio se più d'uno), ed eliminate gli errori tecnici eventualmente segnalati
4. utilizzate dei revisori umani per far controllare la percepibilità e la significatività dei contenuti nelle più disparate condizioni d'uso. Se possibile, organizzate dei veri e propri test di usabilità per verificare i punti che maggiormente si prestano ad interpretazioni soggettive
5. esponete soltanto le dichiarazioni di conformità (bollini o stringhe di testo) di cui siete assolutamente sicuri e che, preferibilmente, possono essere verificate dall'utente:
   • per la conformità ad (X)HTML e CSS, collegate le dichiarazioni ai relativi validatori utilizzati, in modo che chiunque possa ripetere il controllo e verificare direttamente la veridicità della dichiarazione
   • per la conformità ad uno dei tre livelli di accessibilità stabiliti dalle WCAG 1.0, predisponete nel sito una pagina, o almeno una tabella, in cui dichiarate quali controlli di revisione umana sono stati effettuati in aggiunta ai test automatici, e quando e come sono stati eseguiti l'ultima volta
6. non considerate il controllo di accessibilità come un lavoro da fare una volta e poi mai più: ad ogni modifica sostanziale delle pagine, andrebbe ricontrollato tutto, dalla validità del codice al mantenimento del livello di accessibilità dichiarato. Fate tesoro, in particolare, dei riscontri ricevuti dagli utenti: le loro segnalazioni sono preziose per migliorare realmente l'accessibilità e l'usabilità dei vostri documenti

In conclusione di argomento, precisiamo che il più volte citato Bobby non è certo l'unico strumento di controllo automatico dell'accessibilità esistente. Ne esistono altri e vale la pena di provarli. Ognuno di essi, con i suoi pregi ed i suoi difetti, è in grado di fornire allo sviluppatore coscienzioso un tassello in più, un'indicazione in più per migliorare la propria conoscenza dell'accessibilità e dei modi di perfezionarla. Ecco di seguito i più noti tra gli altri strumenti automatici disponibili:

• HTML Tidy - Sviluppato da Dave Raggett, uno dei creatori del linguaggio HTML, è uno strumento a linea di comando molto potente: è in grado di individuare e correggere errori di sintassi (X)HTML e di fornire utili suggerimenti per il miglioramento dell'accessibilità
• LIFT - Sviluppato in collaborazione con Jakob Nielsen, offre strumenti per la valutazione dell'accessibilità e dell'usabilità. E' disponibile a pagamento come programma integrato in DreamWeaver e FrontPage, per l'effettuazione di test in locale durante la fase di sviluppo delle pagine
• Cynthia Says portal - Consente una valutazione dell'accessibilità che si estende in qualche misura anche alla proprietà dei testi alternativi: valuta per esempio la lunghezza dei testi ALT e se questi ripetono il nome dell'immagine a cui si riferiscono
• A-Prompt - Un valutatore dell'accessibilità sviluppato dall'Università di Toronto, da scaricare in locale: è in grado di fornire indicazioni di conformità sia alla Section 508 sia alle WCAG 1.0
• TAW Test accessibilidad web - Programma automatico sul modello di Bobby, in lingua spagnola
• Accessibility Valet - Suddivide la pagina in blocchi di elementi annidati, associando ai singoli elementi eventuali consigli per migliorare l'accessibilità
• Webxact - Strumento di validazione on line della Watchfire, la stessa casa produttrice di Bobby. Offre all'incirca le stesse informazioni di Bobby, ma in un modo più organizzato ed usabile
• Torquemada - Valutatore automatico dell'accessibilità tutto italiano, sviluppato dalla Fondazione Ugo Bordoni
• Lynx viewer - Visualizza in un normale browser grafico una pagina così come la vedrebbe un utente di Lynx: utile per verificare la comprensibilità di una pagina in modalità solo testo, pur senza disporre di Lynx