L'accessibilità, questa sconosciuta
Si sente sempre più spesso parlare di accessibilità, ma cos'è esattamente? Quali sono le regole imposte dalla normativa Italiana? Chi è obbligato e chi è ... "consigliato"? Quali sono gli effetti sull'estetica del sito? Può esistere un CMS accessibile? E, se si, che significa? Che accade se il back-end non lo è? La confusione, in materia, è tanta e in questo clima non è difficile che si cada vittima dei "soliti furbetti del quartiere" (spero che chi ha coniato questa espressione non vi abbia messo il copyright). Vediamo, quindi, di esaminare in dettaglio questi aspetti.
Prima di avventurarci in questa esposizione, mi corre l'obbligo di chiedere umile perdono ai puristi del linguaggio tecnico. In questa esposizione, infatti, non mi atterrò strettamente alla terminologia tecnica. Cercherò, piuttosto, di adattarla in modo tale da renderla il più possibile comprensibile sopratutto a coloro i quali di termini tecnici non comprendono un'acca.
L'accessibilità, cosa è e quali sono gli effetti sull'estetica di un sito web.
Per questo argomento, non posso non fare espresso rinvio all'eccellente esposizione fatta da Ventus85 in questo articolo.
Le disposizioni italiane e ai soggetti obbligati.
In Italia vigono le cosidette norme "Stanca" (la cosidetta Legge Stanca - Legge 04.01.2004, n° 4; DPR 01.03.2005, n° 75; DM 08.07.2005; D.Lgs 07.03.2005, n° 82 - meglio conosciuto come "Codice dell'Amministrazione Digitale" - e successive modifiche e integrazioni).
I soggetti obbligati sono tutte le Pubbliche Amministrazioni, ma l'osservanza è consigliata a tutti i soggetti, siano essi pubbici o privati.
L'accessibilità e il "markup"
Questo è il panorama normativo in Italia, ma in effetti in tutto il mondo vari Stati hanno promulgato proprie norme per definire il proprio concetto di accessibilità. Inoltre, esistono alcuni consorzi sovranazionali che hanno elencato linee guida. In massima parte, queste ultime si limitano all'accertamento del cosidetto markup. Cioè alla verifica che il codice con il quale le pagine vengono scritte sia conforme a quanto dichiarato nei meta del sito (specificatamente nell'header).
Sicchè può esserci un sito W3C conforme se, ad esempio, l'header del sito dichiara che il sistema utilizzato è il "transitional". L'importante è che, poi, il codice HTML effettivamente rispetti tale codifica.
Ciò non significa che il sito sia accessibile. Significa solo che il codice HTML del sito è "pulito". E' Dichiarato "transitional" ed è effettivamente scritto in "linguaggio" transitional.
Ora, una delle basi dell'accessibilità è data dal fatto che la diffusione di strumenti all'avanguardia non è uniforme nel mondo (e neanche nel nostro Paese, a volerla dire tutta).
Esiste ancora hardware che i puristi chiamano "obsoleto" perché non ha un "Dual core Duo" e una ram di almeno 3Gb; esiste hardware che non è nelle condizioni di reggere l'imperante tecnologia Java (giusto per fare qualche esempio). Esiste, inoltre, una vasta parte del territorio che non è raggiunta dall'ADSL.
Questi (ed altri) limiti tecnologici evidentemente escludono dall'accesso alle informazioni Internet offerte da quei siti "disattenti" a questo tipo di esigenze.
Accanto ai limiti di tipo tencologico, poi, ci sono dei limiti soggettivi.
Prendiamo ad esempio un soggetto affetto da epilessia. Anche se non ha limiti di tipo tecnologico, se il malcapitato accedesse a uno di quei siti "tanto carini" pieno di immagini stroboscopiche, a colori cangianti che fanno dire "uuuuhhhhhh quanto è bravo il webmaster" (o web engineering, come è diventato di moda adesso) il minimo che possa capitare è l'insorgenza di una crisi.
E, sempre parlando dei limiti soggettivi, che dire degli ipovedenti o dei non vedenti assoluti? Esistono si delle tecnologie assistive che permettono al browser di "leggere" vocalmente il contenuto di una pagina web, ma se questa non è scritta in modo da essere letta in modo chiaro dal browser, che informazioni assume il soggetto? Basti solo pensare ad un sito dichiarato italiano (nell'header) e che (sempre nell'header della pagina) dichiari la lingua it-IT. Il browser vocale si dispone a leggere in italiano per poi rimanere imbrigliato nelle maglie di una infinità di parole, frasi e financo espressioni idiomatiche in lingua straniera.
Ancora limiti soggettivi per coloro che non hanno un pieno controllo della motilità delle braccia e non possono, quindi, utilizzare il mouse.
Quando si parla di accessibilità, quindi, ci si riferisce certamente al "Markup" (o purezza del linguaggio HTML, come abbiamo visto sopra) che deve rigorosamente essere del tipo "STRICT" - cioè "rigoroso", senza le sbavature concesse dal "transitional" (che potremmo definire come "imbastardito").
Per fare un esempio con le lingue parlate, STRICT possiamo paragonarlo all'inglese della Regina. All'inglese classico e puro che non tollera trasgressioni. Transitional possiamo paragonarlo a quell'inglese che consente l'uso delle variazioni americane, australiane, sudafricane e così via.
Nessuna sbavatura, quindi. Di alcun tipo. Semplicemente SRTICT, in modo che la pagina WEB possa essere agevolmente letta anche in presenza di hardware obsoleto e i browser vocali non debbano fare sforzi "sovrumani" per leggerla
Ma ci si riferisce anche e sopratutto ad una serie di prescrizioni che rendano la pagina "accessibile" anche a chi è affetto da limitazioni di tipo soggettivo.
I loghi "valido W3C" che tanto sono diventati di moda nei siti WEB delle Pubbliche Amministrazioni Italiane, quindi sono una solenne presa in giro. Il sito in questione è semplicemente illegale come lo sono gli altri che, senza quel logo, almeno non hanno la presunzione di prendere per i fondelli l'utenza!!
E veniamo adesso all'accessibilità vera e propria e addentriamoci nella
legislazione italiana.
Cominciamo col mettere in chiaro che le disposizioni "Stanca" sono fra le più restrittive al mondo. Section 508 (l'accessibilità secondo le norme americane) è acqua fresca.
In Italia le disposizioni che regolano la materia sono, nell'ordine:
1) Legge 04/01/2004, n° 4;
2) Regolamento di attuazione della Legge 9 gennaio 2004, n. 4 per favorire l'accesso dei soggetti disabili agli strumenti informatici collegamento esterno, approvato con Decreto del Presidente della Repubblica, 1 marzo 2005, n. 75, pubblicato sulla Gazzetta Ufficiale n. 101 del 3 maggio 2005, attuativo dell'articolo 10 della Legge 4/2004;
3) Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici, approvati con Decreto Ministeriale 8 luglio 2005, pubblicato sulla Gazzetta Ufficiale n. 183 dell'8 agosto 2005, attuativo dell'articolo 11 della Legge 4/2004;
4) Codice dell'amministrazione digitale, ci riferiamo al Decreto Legislativo 7 marzo 2005, n. 82 , pubblicato sulla Gazzetta Ufficiale n. 112 del 16 maggio 2005, modificato e integrato dal Decreto Legislativo 4 aprile 2006, n. 159
Per avere una idea circa la reale portata di queste norme, basta solo fare riferimento al "sito dell'Italia" che tanto fece discutere la rete: italia.it. Era un progetto creato dallo stesso governo italiano all'inizio del 1997. Costato ben 45 milioni di Euro (si, dicansi quarantacinquemilioni di euro). Ben lungi dall'essere accessibile (eppure creato dallo stesso Governo Italiano, in barba alle sue stesse Leggi) il sito venne, poi chiuso verso la fine dello stesso anno 2007.
Ma allora è impossibile creare siti accessibili in Italia? Certamente no:
L'accessibilità con Joomla!
Joomla! ha un progetto accessibile realizzato dalla comunità italiana di Joomla.it: Joomla FAP (Joomla For All People)
Joomla!FAP non è diverso da Joomla! Anzi è Joomla! Va installato Joomla 1.5.x (in atto 1.5.8) e su di esso applicate le modifiche previste dal FAP.
Anzi, per venire incontro alle richieste, è in programma la pubblicazione di un pacchetto di installazione completo del JoomlaFAP.
Joomla!FAP è costituito da un template accessibile, da un componente accesskey, alcune modifiche al core (non modifiche talmente strutturali da comprometterne la sicurezza) e HTMLpurifier (che si trova fra le estensioni di joomla.org al link indicato nel forge di joomlaFAP).
Joomla!FAP è sicuramente accessibile dal lato front-end, non lo è dal lato back-end.
Il back-end di un CMS, deve essere anch'esso accessibile?
Secondo alcuni, questo costituirebbe una violazione della Legge Stanca, ma vogliamo provare a capire, per evitare di farci turlupinare?
Cosa è il back-end di un CMS? Il back-end costituisce il "lato gestionale" del CMS. Costituisce l'interfaccia che non è destinato a "erogare" servizi e informazioni. Il back-end, piuttosto, riceve le informazioni per metterle a disposizione dell'utenza - sotto forma di pagine web - attraverso il front-end. In breve, il back-end è lo strumento attraverso il quale devono essere resi servizi accessibili.
Allora, cosa significa "back-end accessibile"? Significa forse che le iconcine del "salva", "cestina", "annulla", ecc debbano avere le descrizioni sintetiche ed estese? Significa che le immagini hanno il testo alternativo?
Significa che il template del back-end è "tabless" e che, in quei pochi casi in cui esistano le tabelle, queste abbiano tutte le descrizioni (cella per cella) e possono essere "lette" in modo linearizzato?
Significa che la pagina può essere letta senza l'ausilio del css?
Ma vogliamo ragionare?
Come può, la mancata rispondenza del back-end alle regole di accessibilità costituire violazione della Legge Stanca?
Esaminiamo meglio la situazione e comprenderemo:
L'articolo 1 della Legge, nel declamare gli obiettivi da garantire, recita:
"il diritto di accesso ai servizi informatici e telematici della pubblica amministrazione e ai servizi di pubblica utilità da parte delle persone disabili"
Nella stessa direzione, l'art 2 nel definire il concetto di accessibilità utilizza la locuzione:
"capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari"
Nello stesso senso anche l'articolo 2 del Decreto Ministeriale 8 luglio 2005 allorquando parla di fornitura di informazioni ed erogazione di servizi.
Ora, ovviamente il back-end, quale lato amministrativo o gestionale del CMS, non fornisce alcuna informazione e non eroga alcun servizio, ma "riceve" tutto questo per, ribadisco, renderlo disponibile all'utenza.
Se il dipendente che è stato attribuito al servizio di inserimento di notizie dal back-end ha la necessità di accorgimenti per l'accessibilità, come dovrebbe riuscire a inserire una immagine? Come dorebbe poter inserire egli stesso le descizioni e il testo alternativo? Come dovrebbe poter costruire le tabelle (solo quando necessarie, ovviamente)? Come dovrebbe ...
In buona sostanza, come dovrebbe poter costruire un contenuto che sia significativo e, sopratutto, sia accessibile? Chi vuol togliersi la curiosità, clicchi con il pulsante destro del mouse sull'immagine del logo dell'accessibilità CNIPA in alto in questa pagina per vederne le proprietà e leggerà una serie di informazioni. Altre informazioni (la descrizione estesa) vengono memorizzate in file di testo e dati come attributo alle immagini (longdesc). Nel caso di quell'immagine, un testo possibile è: "Immagine rappresentante un computer stilizzato, limitato al video e alla tastiera, tutto di colore arancione. Dal video sembrano uscire tre figure umane stilizzate, due dall'angolo inferiore sinistro e una dall'angolo inferiore destro.
Le figure nell'angolo sinistro sono una di colore blu aviazione e una di colore azzurro cielo, mentre la figura nell'angolo destro è di colore rosso.
Tutte e tre le figure hanno le braccia aperte".
Quelle sono le informazioni che i browser vocali leggono ad alta voce per i non vedenti. La descrizione estesa di una immagine deve essere intesa come se "si stesse raccontando al telefono l'immagine ad un amico"!!!
Chi dovrebbe mai inserire queste informazioni se il dipendente addetto al back-end del sito dovesse essere anche solo ipovedente?
Non vale neppure invocare che:
* i dipendenti di una pubblica amministrazione possono (e debbono, in parte) essere disabili;
* deve essere garantita parità di trattamento e condizioni lavorative.
Esistono mansioni che non possono in nessun caso essere svolte da chi è affetto da talune disabilità. Si pensi a mansioni di facchinaggio, operai, giardinieri, autisti e una infinità di altre.
Nessun essere pensante immaginerebbe un sordomuto al centralino o all'URP. Nessun essere con un minimo di raziocinio assegnerebbe a un non vedente o a un soggetto con forti limitazioni della motilità brachiale le mansioni di giardiniere.
Fossi io il dipendente in questione sporgerei immediatamente denuncia per mobbing!!!
Ma perché, quindi, dovrebbe la gestione del sito web istituzionale di un ente pubblico non essere ricompreso fra le mansioni che non possono essere assegnate a dipendenti che manifestino particolari disabilità (tali da essere essi stessi fra i destinatari delle disposizioni sull'accessibilità). Forse giusto per consentire a qualcuno di asserire che al di fuori di un determinato software, di accessibile non c'è nulla?
La gestione del back-end, indubitabilmente è una mansione che, semplicemente, NON PUO' essere assegnata a dipendenti le cui disabilità rendono l'inserimento delle informazioni e l'erogazione dei servizi - di cui il sito web costituisce uno strumento e veicolo - non solo estremamente gravoso, ma obiettivamente impossibile.
Joomla!FAP, quindi, risponde ai requisiti richiesti alla legge italiana e non solo. Basta lanciare un test con gli unici validatori automatici esistenti in rete :
http://checker.atrc.utoronto.ca/index.html e http://www.webagogo.be (nel momento in cui scrivo, il secondo è fuori servizio).
Rimane ovvio che la costruzione di un sito accessibile non si limita all'istante dell'installazione. L'accessibilità necessita di cura costante da parte del gestore del sito. A lui spetta, ad esempio, l'inserimento delle descrizioni, l'attribuzione di una nuova access key ad ogni nuova voce di menu significativa, l'evitare l'eccessivo uso di termini in altra lingua che non sia quella dichiarata nell'header, inserire testi ancora significativi per i link, inserire sommari di tabella e attributi di righe ...
Joomla!FAP offre gli strumenti per tutto questo, ma non può sostituirsi all'operatore.
Nessuno sturmento informatico attualmente disponibile consente questo. Chi promette il contrario, semplicemente mente!!
In ogni caso, un ottimo riassunto delle caratteristiche di joomlaFAP lo trovate qui: http://www.itopen.it
Alcune note sul "bollino"
Infine, per quanto riguarda il "bollino", il Decreto del Presidente della Repubblica n. 75 del 1 marzo 2005 dispone che le Pubbliche Amministrazioni autocertifichino l'accessibilità del sito, dopo aver richiesto dichiarazione di conformità al fornitore.
L'autocertificazione di conformità, in uno con la dichiarazione di conformità emessa dal fornitore del sito, va "segnalata" (art. 8 comma 1 del Decreto) al CNIPA (non al Ministero dell'Innovazione Tecnologica) .
L'art. 9 comma 2 dello stesso Decreto, poi, dispone che:
"1. Nelle procedure svolte dai soggetti di cui all'articolo 3, comma 1, per l'acquisto di beni e per la fornitura di servizi informatici, i requisiti di accessibilità stabiliti con il decreto di cui all'articolo 11 costituiscono motivo di preferenza a parità di ogni altra condizione nella valutazione dell'offerta tecnica, tenuto conto della destinazione del bene o del servizio. La mancata considerazione dei requisiti di accessibilità o l'eventuale acquisizione di beni o fornitura di servizi non accessibili è adeguatamente motivata.
2. I soggetti di cui all'articolo 3, comma 1, non possono stipulare, a pena di nullità, contratti per la realizzazione e la modifica di siti INTERNET quando non è previsto che essi rispettino i requisiti di accessibilità stabiliti dal decreto di cui all'articolo 11. I contratti in essere alla data di entrata in vigore del decreto di cui all'articolo 11, in caso di rinnovo, modifica o novazione, sono adeguati, a pena di nullità, alle disposizioni della presente legge circa il rispetto dei requisiti di accessibilità, con l'obiettivo di realizzare tale adeguamento entro dodici mesi dalla data di entrata in vigore del medesimo decreto.
Ai sensi dell'articolo 7, comma 1, lettera b), della legge n. 4 del 2004, la Presidenza del Consiglio dei ministri - Dipartimento per l'innovazione e le tecnologie, avvalendosi del Cnipa, previa comunicazione inviata all'amministrazione statale interessata, verifica il mantenimento dei requisiti di accessibilità dei siti e dei servizi forniti e dà notizia dell'esito di tale verifica al dirigente responsabile; qualora siano riscontrate anomalie, viene richiesta all'amministrazione statale medesima la predisposizione del relativo piano di adeguamento con l'indicazione delle attività e dei tempi di realizzazione."
Giusto per concludere,
I bandi pubblici
Diffidare dei bandi pubblici che non prevedano espressamente la rispondenza dei siti web pubblici alle disposizioni "Stanca". Da qualche parte c'è il trucco. La Legge, infatti prevede che:
L'inosservanza delle disposizioni della presente legge comporta responsabilità dirigenziale e responsabilità disciplinare ai sensi degli articoli 21 e 55 del decreto legislativo 30 marzo 2001, n. 165, ferme restando le eventuali responsabilità penali e civili previste dalle norme vigenti. Se quindi, un bando non dovesse espressamente prevedere la rispondenza alle disposizioni Stanca, significa semplicemente che non potrà non vincere quell'unico progetto rispondente. A buon intenditor ...
