La legge italiana sull’accessibilità

La legge 4/2004: nobili fini, scarsi strumenti

Sull’onda delle iniziative per l’anno del disabile, celebrato nel 2003, il 9 gennaio dell’anno successivo viene promulgata dal Presidente della Repubblica, dopo l’approvazione dei due rami del Parlamento e con il consenso pressoché unanime delle varie parti politiche, la legge 4/2004 , intitolata Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici, nota anche come “legge Stanca”, dal nome dell’allora ministro per l’innovazione e le tecnologie Lucio Stanca.

L’Italia si è così dotata fin dal 2004, ponendosi all’avanguardia rispetto alla maggior parte delle altre nazioni, di uno strumento legislativo pensato per tutelare il diritto degli utenti con disabilità a fruire degli strumenti informatici, e in particolare di Internet, senza subire discriminazioni rispetto ai cosiddetti “normodotati”. Per dare un riferimento alto ai diritti che intende tutelare, la legge 4/2004 si richiama esplicitamente (art. 1, comma 2) all’articolo 3 della Costituzione italiana, che stabilisce che “Tutti i cittadini hanno pari dignità sociale e sono eguali davanti alla legge, senza distinzione di sesso, di razza, di lingua, di religione, di opinioni politiche, di condizioni personali e sociali”.

La legge sull’accessibilità nasce così all’insegna delle più nobili e condivisibili finalità. Tuttavia, come spesso accade nelle cose italiane, i buoni propositi su cui essa è imperniata non sono bastati, almeno finora, a renderla uno strumento realmente adeguato alle necessità. Scorrendo i suoi articoli, si scoprono, infatti, alcuni vincoli che ne diminuiscono di molto l’efficacia.

Il vincolo dell’appartenenza al settore pubblico

Il primo vincolo è definito all’articolo 3 comma 1, che stabilisce:

La presente legge si applica alle pubbliche amministrazioni (...), agli enti pubblici economici, alle aziende private concessionarie di servizi pubblici, alle aziende municipalizzate regionali, agli enti di assistenza e di riabilitazione pubblici, alle aziende di trasporto e di telecomunicazione a prevalente partecipazione di capitale pubblico e alle aziende appaltatrici di servizi informatici.

Non è nostro scopo elencare tutti i soggetti obbligati al rispetto della legge 4/2004 (per questo rimandiamo all’appendice di Lorenzo Spallino, alla fine del volume). Quel che emerge dalla lettura del comma citato è che la legge sull’accessibilità si applica principalmente ai soggetti pubblici, e ai privati solo nella misura in cui hanno a che fare con il settore pubblico per via di concessioni o di prevalenti partecipazioni di capitali. Restano esclusi così dall’obbligo di applicare la legge i soggetti privati che agiscono con fini e capitali privati, i quali possono pertanto continuare a creare o mantenere siti web inaccessibili.

Intendiamoci: obbligare i siti pubblici al rispetto della legge sull’accessibilità è di certo cosa utile, anzi indispensabile, ma non basta. Il lasciare i gestori di siti web privati liberi da qualsiasi obbligo di adeguamento all’accessibilità mantiene di fatto una situazione di discriminazione a danno delle persone con disabilità. È come se il legislatore avesse valutato il Web una realtà di serie B rispetto al mondo fisico. Mentre, per esempio, un’apposita legge (Legge 9 gennaio 1989, n. 13 , Disposizioni per favorire il superamento e l’eliminazione delle barriere architettoniche negli edifici privati) stabilisce che un edificio privato aperto al pubblico ha l’obbligo di rimuovere le barriere architettoniche che impediscono ai portatori di handicap di accedervi, nulla di simile viene stabilito dalla legge 4/2004 per quegli “edifici” virtuali aperti al pubblico che sono i siti web privati. Così, si arriva alla situazione piuttosto paradossale che, mentre un supermercato su strada deve avere per legge rampe e scivoli che permettano a un disabile motorio di entrare e di uscire, se lo stesso supermercato vende i suoi prodotti anche sul Web, il suo sito può essere tranquillamente inaccessibile (in realtà la legge 4/2004 contiene disposizioni pensate per invitare i soggetti privati a rendere i propri siti accessibili e di alta qualità, ma di fatto non li obbliga in alcun modo).

Questo difetto di tutela non ha mancato di suscitare proteste tra gli utenti con disabilità. Riportiamo, a tal proposito, ciò che ci ha scritto in forma di comunicazione privata un non vedente, Leo Maria Cerreta (già citato nei capitoli precedenti a proposito di argomenti tenici):

Io, come penso anche altri disabili, non passiamo la vita a navigare i siti delle pubbliche amministrazioni. L’accessibilità dei siti della PA è certamente cosa utile e quindi da perseguire, ma l’integrazione dei disabili nella rete, e quindi nella società, non passa mica solo dai siti web della PA. Anzi, paradossalmente, direi che sono quasi più importanti i siti delle realtà private. Il web si sarebbe mai diffuso se fosse stato un contenitore di soli siti istituzionali? Un disabile, specialmente se ha problemi nel muoversi, credo che dalla rete si aspetti servizi accessibili, come home banking, e-commerce di qualsiasi genere, luoghi di incontro e aggregazione in rete, risorse per lo studio e l’apprendimento, e tutti quei contenuti per i quali una persona oggi decide di attivare un abbonamento a Internet. Non ho mai trovato nessuno che mi avesse detto di aver attivato una linea ADSL per visitare i siti della PA: perché diavolo pensano che lo vogliano fare i disabili? Quindi, per me, la Stanca, o chi per essa, avrà successo quando saranno questi i servizi e contenuti accessibili, non il piano regolatore della mia città.

Difficile dar torto a Cerreta. Certo, imporre l’accessibilità per legge, indiscriminatamente, a tutti i siti privati sarebbe stata un’azione velleitaria e priva di reali possibilità di applicazione. È utopistico, infatti, pensare che il dilettante che realizza il proprio sitino personale, possa riuscire, senza un’adeguata formazione professionale nel campo dei linguaggi per il Web, ad applicare le complesse specifiche tecniche allegate alla legge 4/2004. Ma, lasciando fuori i dilettanti, sarebbe stato invece utile e desiderabile, se la legge avesse inserito tra i soggetti erogatori elencati all’articolo 3 anche i tanti soggetti privati che offrono servizi di interesse pubblico, per esempio – per dirne solo alcuni – quotidiani, portali di web mail, telefonia, condivisione video, siti di home banking, di commercio elettronico, di e-learning. Vi sono privati che offrono, di propria iniziativa, siti più o meno sufficienti dal punto di vista dell’accessibilità, ma la maggior parte sembra essere purtroppo indifferente al problema.

Inizio pagina

Il vincolo dell’esistenza di un contratto

Il secondo vincolo che agisce negativamente sull’efficacia della legge è quello che lega l’applicazione dei requisiti di accessibilità unicamente all’esistenza di un contratto. Rimandiamo per maggiori dettagli all’appendice di Lorenzo Spallino, ma vale qui la pena di attirare l’attenzione del lettore sulla prima parte del comma 2 dell’articolo 4 della Legge 4/2004, che dice:

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.

La sanzione della nullità rende privi di effetti, come se non fossero mai stati stipulati, i contratti che non contemplano l’implementazione dei requisiti di accessibilità definiti nel decreto attuativo richiamato dall’articolo 11. Inoltre, all’articolo 9 si aggiunge un’ulteriore sanzione, quella della responsabilità dirigenziale e disciplinare per “l’inosservanza delle disposizioni della presente legge”. Queste sanzioni, che pure sono state pensate per scoraggiare l’elusione della legge da parte degli enti che rientrano nella categoria dei “soggetti erogatori”, hanno però il limite di non sanzionare in alcun modo i siti web gestiti internamente dalle pubbliche amministrazioni, e quindi realizzati senza contratto di sorta, una situazione che, soprattutto nelle piccole realtà locali, è piuttosto frequente.

Così, in mancanza di sanzioni che riguardino l’accessibilità in generale e non i contratti, un qualsiasi ente pubblico che possiede un sito inaccessibile, realizzato e gestito con modalità amatoriali da dipendenti dell’amministrazione stessa, può lecitamente continuare a gestirlo con le stesse modalità anche per il futuro, non avendo alcun obbligo di applicare i requisiti tecnici allegati alla legge 4/2004.

È evidente che si crea in tal modo una situazione discriminante, che ruota intorno alla presenza (o all’assenza) di un contratto stipulato dall’amministrazione con società fornitrici. Ma anche quando il contratto c’è, l’efficacia della legge è a rischio. Secondo il comma 1 dell’articolo 4, è possibile, infatti, acquistare beni e servizi anche non accessibili, purché si motivi adeguatamente la decisione (“La mancata considerazione dei requisiti di accessibilità o l’eventuale acquisizione di beni o fornitura di servizi non accessibili è adeguatamente motivata”). Basta allora un problema di bilancio – quale amministrazione oggi non ne ha? – per fornire un aggancio sufficiente a giustificare la stipulazione di un contratto che non menzioni il rispetto dei requisiti di accessibilità stabiliti dalla legge.

Insomma, così com’è oggi, la legge italiana sull’accessibilità, per quanto sia e resti una manifestazione importante e lodevole di volontà politica contro una delle forme di discriminazione più sottili e insidiose (quella che vincola l’accesso ai servizi informatici al possesso di determinate abilità fisiche o cognitive), non è in grado di produrre gli effetti sperati. Troppi sono i soggetti che possono legalmente ignorare l’applicazione dei requisiti di accessibilità e poco efficaci si sono rivelate, almeno finora, anche le misure sanzionatorie e di controllo.

Ne è una prova lo scarno elenco presente sul sito del CNIPA, il Centro Nazionale per l’Informatica nella Pubblica Amministrazione, che tiene traccia di tutti i soggetti erogatori che dichiarano formalmente di essere conformi ai requisiti tecnici della legge 4/2004 (acquisendo così il diritto di esporre un apposito logo). Al momento in cui scriviamo – giugno 2007 – solo 61 siti web sono presenti nell’elenco . Se consideriamo che il decreto attuativo contenente i requisiti tecnici per l’applicazione della legge è stato promulgato a luglio 2005, ci sono voluti quasi due anni per avere 61 siti che si dichiarano pubblicamente conformi alla legge. E le altre migliaia e migliaia di amministrazioni pubbliche che pure rientrano tra i soggetti erogatori, che hanno fatto nel frattempo? Hanno adeguato, o progettano di adeguare, i propri siti web alle specifiche di accessibilità previste dalla legge? Li hanno forse già resi accessibili, ma non lo dichiarano? Non si sa.

Inizio pagina

Un tipico conflitto d’interessi all’italiana

Oltre i due vincoli citati nei paragrafi precedenti, c’è un terzo limite, che contribuisce a diminuire l’efficacia della legge 4/2004 per quanto riguarda l’accessibilità dei contenuti web. Ci riferiamo all’articolo 8 del regolamento di attuazione, promulgato con il decreto del Presidente della Repubblica n. 75 del 1° marzo 2005. L’articolo si compone di un unico comma, che dice:

Le amministrazioni pubbliche e comunque i soggetti di cui all’articolo 3, comma 1, della legge n. 4 del 2004, che intendono utilizzare il logo sui siti e sui servizi forniti, provvedono autonomamente a valutare l’accessibilità sulla base delle regole tecniche definite con il decreto del Ministro per l’innovazione e le tecnologie, di cui all’articolo 11 della legge n. 4 del 2004; la valutazione positiva, previa segnalazione al Cnipa, consente l’utilizzo del logo.

L’autonomia delle pubbliche amministrazioni nella valutazione dell’accessibilità dei propri siti web è ribadita, inoltre, dal comma 4 dell’articolo 3 del medesimo decreto, che afferma:

Nell’accertamento dei requisiti di accessibilità dei servizi, acquisiti con le procedure o realizzati tramite i contratti di cui all’articolo 4, commi 1 e 2, della legge n. 4 del 2004, le amministrazioni interessate possono acquisire il parere non vincolante di un valutatore iscritto nell’elenco di cui al comma 1.

È possibile, cioè, ricorrere a un valutatore professionista, iscritto a un apposito albo ed esterno all’amministrazione, ma il suo parere è puramente consultivo, non vincolante, come è invece nel caso delle valutazioni di accessibilità richieste dai soggetti privati, secondo quanto stabilisce il comma 2 dell’articolo 4 del decreto:

I soggetti privati si rivolgono a uno dei valutatori che, svolta la sua attività, in caso di esito positivo, rilascia attestato di accessibilità, con validità non superiore a dodici mesi [...].

Tutto ciò evidenzia, a nostro avviso, un palese conflitto d’interessi, che riguarda la determinazione del possesso dei requisiti di accessibilità nei siti pubblici: il decreto consente, infatti, alle pubbliche amministrazioni di autocertificare il possesso di tali requisiti. A tal fine è sufficiente compilare un modello prestampato (Rapporto conclusivo di accessibilità ).

Insomma, controllore e controllato finiscono per coincidere. Si pensi se un simile criterio fosse esteso ad altri ambiti della vita pubblica in cui contano i diritti e le garanzie: sarebbe forse di beneficio per la salute dei cittadini se, per esempio, una società farmaceutica potesse autocertificare che una propria medicina guarisce senza produrre alcun effetto collaterale, e questa autocertificazione valesse seduta stante come autorizzazione ministeriale per la vendita del prodotto nelle farmacie?

In realtà, il CNIPA dovrebbe vigilare sull’effettivo possesso dei requisiti di accessibilità per tutti i siti che si dichiarano conformi alla legge, secondo quanto afferma il primo comma dell’articolo 7 della legge 4/2004:

1. La Presidenza del Consiglio dei ministri - Dipartimento per l’innovazione e le tecnologie, anche avvalendosi del Centro nazionale per l’informatica nella pubblica amministrazione [...]:

1. effettua il monitoraggio dell’attuazione della presente legge;
2. vigila sul rispetto da parte delle amministrazioni statali delle disposizioni della presente legge; [...]

Questi poteri di vigilanza sono poi ribaditi dal comma 2 dell’articolo 9 del decreto del 1° marzo 2005, che dice:

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.

Basta però esaminare anche superficialmente le pagine di qualcuno dei 61 siti presenti nell’elenco pubblico del CNIPA, per scoprire che queste verifiche per il momento non sembrano essere state fatte e che le autocertificazioni sono in più di un caso – come dire? – “generose” e poco veritiere nei confronti del sito a cui sono riferite.

Del resto, il CNIPA spiega chiaramente qual è la situazione corrente, per quanto riguarda la vigilanza sull’applicazione della legge 4/2004. Lo fa in un documento del 5 luglio 2006, intitolato Un contributo alla chiarezza , al paragrafo 4 del quale si può leggere:

vigilanza: non è previsto, non è voluto e non è possibile alcun intervento normativo o di controllo a livello centrale; ciascuna Amministrazione Territoriale deve poter operare, per precisa volontà politica, in piena autonomia ed è quindi direttamente responsabile degli adempimenti di legge.

Fatta salva l’autonomia delle singole amministrazioni, la legge – in base agli articoli che abbiamo citato – investe però chiaramente il CNIPA dei doveri di vigilanza sull’applicazione dei requisiti di accessibilità da parte dei soggetti erogatori.

E infatti, in un altro documento, datato 23 aprile 2007, vengono descritte le attività di monitoraggio per il 2006 e il 2007 sull’implementazione dell’accessibilità in alcuni siti delle pubbliche amministrazioni centrali:

Nel 2006, il CNIPA ha eseguito un primo monitoraggio sperimentale su 24 siti pubblici, grazie al quale sono stati resi pienamente conformi alla normativa 8 siti e sono state fornite indicazioni sul processo di adeguamento per i restanti 16. L’attività del 2006 è servita anche a perfezionare la metodologia di monitoraggio che sarà applicata quest’anno nella versione aggiornata.

Nel 2007 sarà effettuato il monitoraggio di 42 siti che prevede una prima fase di verifica, l’impegno delle amministrazioni a curare gli interventi di adeguamento, e una fase finale di accertamento del buon esito delle modifiche apportate. Le amministrazioni sono state invitate a proporre in tempi rapidi al CNIPA le proprie candidature, sulla base delle quali sarà definito l’insieme dei siti sottoposti a monitoraggio nel 2007.

Senza voler entrare in dettagli noiosi, crediamo che i cittadini con disabilità, principali beneficiari della legge 4/2004, abbiano bisogno di ben altre garanzie che un’autocertificazione e il monitoraggio di una sessantina di siti pubblici, se vogliono veder rispettato il proprio diritto a usare il Web (o almeno quella parte del Web coperta dall’attuale legge) senza subire discriminazioni nella possibilità di accedere a contenuti e servizi online.

Non possiamo fare a meno di pensare, infatti, alle migliaia di siti pubblici che, a oltre tre anni dall’entrata in vigore della legge 4/2004 e a oltre due anni dall’entrata in vigore del decreto di attuazione contenente i requisiti tecnici per l’accessibilità, sembrano aver semplicemente ignorato l’esistenza di questa legge o essersi limitati, tutt’al più, a un’implementazione sui generis, basata su criteri non riconducibili ai requisiti tecnici previsti dalla legge stessa.

Inizio pagina

Il PDL 1226

Per fortuna, qualcuno si è mosso, nel tentativo di migliorare la scarsa capacità dell’attuale legge di perseguire i fini per cui era stata promossa.

In particolare, i deputati Campa e Palmieri, che già avevano presentato alla fine del 2002 una proposta di legge sull’accessibilità (PDL 3486 - PDF, 162 kB), hanno presentato alla Camera dei Deputati, il 28 giugno 2006, una proposta di adeguamento della legge 4/2004, registrata come PDL 1226 .

Si tratta di una proposta costituita da un unico articolo suddiviso in due commi, che recita:

1. Dopo il comma 2 dell’articolo 4 della legge 9 gennaio 2004, n. 4, è inserito il seguente:
   2-bis. I soggetti di cui all’articolo 3, comma 1, garantiscono comunque il rispetto dei requisiti di accessibilità stabiliti dal decreto di cui all’articolo 11 in tutti i casi di creazione o modifica di siti INTERNET di propria competenza.
2. Al comma 2 dell’articolo 7 della legge 9 gennaio 2004, n. 4, sono aggiunte, in fine, le seguenti parole: , anche avvalendosi del Comitato regionale per le comunicazioni competente per territorio.

Come si evince dalla frase che abbiamo messo in grassetto, l’articolo 2-bis si propone di sanare il difetto legato alla necessità che vi sia un contratto per la modifica o la creazione di un sito web, affinché scatti l’obbligo di applicare i requisiti tecnici di accessibilità previsti dalla legge (o, più precisamente, scatti l’obbligo che i requisiti di accessibilità siano menzionati tra le prestazioni previste dal contratto).

Se, infatti, dovesse essere approvata la proposta dei deputati Campa e Palmieri, tutti i “soggetti erogatori” previsti al comma 1 dell’articolo 3 della legge 4/2004 sarebbero obbligati ad applicare i requisiti di accessibilità anche in mancanza di un contratto.

Il secondo comma dell’art. 1 del PDL 1226 propone, poi, di sanare il problema della debolezza dei controlli sull’applicazione della legge, delegando ai Corecom, cioè ai Comitati regionali per le comunicazioni, il compito di supportare il CNIPA nelle sue funzioni di controllo.

Nel tentativo di sollecitare modifiche migliorative alla legge 4/2004, si è mossa ufficialmente anche l’associazione di sviluppatori IWA Italy (International Webmasters Association Italia) che, tramite il suo presidente Roberto Scano, ha inviato il 30 ottobre 2006 una lettera ai membri della IX Commissione Trasporti della Camera dei Deputati e, per conoscenza, al Ministro per le Riforme e le Innovazioni nella Pubblica Amministrazione, Luigi Nicolais. Nella lettera Scano, tra le altre cose, scrive:

(...) visti i tempi di evoluzione del Web rispetto ai tempi di evoluzione delle normative, chiedo come presidente dell’associazione sviluppatori esperti in materia di accessibilità di attuare quanto prima delle modifiche alla Legge 4/2004 al fine di garantirne l’applicabilità senza elusione e con possibilità di un reale controllo di applicazione, nonché di valutare la nascita di un gruppo permanente di studio sull’accessibilità e l’innovazione nel settore Web che mantenga la normativa allineata con le norme tecniche emanate dai consorzi quali W3C e ISO.

Per quanto ci è dato sapere, il Parlamento italiano sembra impegnato al momento in tutt’altre faccende. Non si vede purtroppo all’orizzonte la possibilità di un intervento legislativo rapido, che possa affilare le armi spuntate di cui dispone l’attuale legge italiana sull’accessibilità.

Inizio pagina

I requisiti per l’accessibilità definiti dal DM 8 luglio 2005

Per una trattazione più approfondita degli aspetti giuridici che riguardano la legge sull’accessibilità, rimandiamo alla già citata appendice di Spallino, alla fine del volume.

Nel resto del capitolo, ci occuperemo invece delle norme tecniche contenute nei decreti di attuazione e, in particolare, dei requisiti per l’accessibilità dei siti web, che sono la parte che veramente ci interessa per gli scopi di questo libro.

Definizioni, fini e metodi

Vediamo, innanzitutto, cosa la legge 4/2004 intende per “accessibilità”. Secondo la definizione contenuta nell’articolo 2, l’accessibilità è:

la 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.

Il comma 1 dell’articolo 2 del decreto di attuazione n. 75 del 1° marzo 2005 definisce i fini a cui la legge tende nel perseguimento dell’accessibilità, e i criteri con cui intende raggiungere quei fini (il corsivo è nostro):

Sono accessibili i servizi realizzati tramite sistemi informatici che presentano i seguenti requisiti:

1. accessibilità al contenuto del servizio da parte dell’utente;
2. fruibilità delle informazioni offerte, caratterizzata anche da:
   1. facilità e semplicità d’uso, assicurando, fra l’altro, che le azioni da compiere per ottenere servizi e informazioni siano sempre uniformi tra loro;
   2. efficienza nell’uso, assicurando, fra l’altro, la separazione tra contenuto, presentazione e modalità di funzionamento delle interfacce, nonché la possibilità di rendere disponibile l’informazione attraverso differenti canali sensoriali;
   3. efficacia nell’uso e rispondenza alle esigenze dell’utente, assicurando, fra l’altro, che le azioni da compiere per ottenere in modo corretto servizi e informazioni siano indipendenti dal dispositivo utilizzato per l’accesso;
   4. soddisfazione nell’uso, assicurando, fra l’altro, l’accesso al servizio e all’informazione senza ingiustificati disagi o vincoli per l’utente;
3. compatibilità con le linee guida indicate nelle comunicazioni, nelle raccomandazioni e nelle direttive sull’accessibilità dell’Unione europea, nonché nelle normative internazionalmente riconosciute e tenendo conto degli indirizzi forniti dagli organismi pubblici e privati, anche internazionali, operanti nel settore, quali l’International Organization for Standardization (ISO) e il World Wide Web Consortium (W3C).

Dalla lettura di questo comma possiamo ricavare due caratteristiche essenziali dell’impianto tecnico su cui si basa la legge 4/2004:

1. la fusione degli obiettivi dell’accessibilità con quelli dell’usabilità. Infatti, la separazione tra contenuto e presentazione, la possibilità di indirizzare i contenuti a diversi canali sensoriali, l’indipendenza dal dispositivo di accesso sono tutti strumenti propri dell’accessibilità; al contempo, facilità, semplicità d’uso, efficacia, efficienza e soddisfazione sono caratteristiche proprie dell’usabilità;
2. il riferimento alle linee guida internazionali sull’accessibilità. I requisiti tecnici per l’accessibilità dei siti pubblici, come vedremo tra breve, si basano esplicitamente sulle WCAG 1.0, che, in più di un caso, sono riprese quasi letteralmente. Sono usati come riferimento anche i requisiti della legge statunitense sull’accessibilità (la cosiddetta Section 508), la quale, a sua volta, è derivata dalle WCAG 1.0.

Inizio pagina

Livelli e loghi di accessibilità. La verifica soggettiva

I requisiti per l’implementazione e la verifica dell’accessibilità sono definiti nel decreto ministeriale dell’8 luglio 2005 , intitolato Requisiti tecnici e i diversi livelli per l’accessibilità agli strumenti informatici.

Il decreto definisce per i siti web due livelli di accessibilità, che fanno capo a due diverse metodologie: la verifica tecnica e la verifica soggettiva, divisa quest’ultima, a sua volta, in tre livelli di qualità.

I due livelli principali sono stratificati: non si può accedere alla verifica soggettiva, se non c’è già stata un’applicazione integrale dei requisiti che fanno parte della verifica tecnica.

Gli enti che appartengono alla categoria dei “soggetti erogatori”, definita nel comma 1 dell’articolo 3 della legge (citato all’inizio di questo capitolo), sono obbligati alla sola implementazione dei requisiti tecnici, del cui possesso garantiscono – come abbiamo visto – tramite un’autovalutazione.

I requisiti tecnici sono ventidue e sono definiti nell’allegato A del decreto ministeriale dell’8 luglio 2005, intitolato Verifica tecnica e requisiti tecnici di accessibilità delle applicazioni basate su tecnologie internet. Li esamineremo uno per uno successivamente.

Il conseguimento di questo livello base di accessibilità, certificato nei modi stabiliti dalla legge, dà diritto a esporre il logo mostrato in Figura 21.1 A.

La verifica soggettiva si rivolge, invece, principalmente a quei privati che siano interessati a pubblicare siti web certificati dal punto di vista della qualità, in grado di garantire agli utenti non solo accessibilità, ma anche un’esperienza di fruizione piacevole e soddisfacente.

Metodi e finalità della verifica soggettiva sono definiti nell’allegato B del decreto ministeriale dell’8 luglio 2005, intitolato Metodologia e criteri di valutazione per la verifica soggettiva dell’accessibilità delle applicazioni basate su tecnologie internet.

Tale verifica viene eseguita da valutatori professionisti, iscritti a un apposito albo istituito presso il CNIPA.

La prima fase della verifica consiste di un’attività cosiddetta di “simulazione cognitiva”, in cui l’esperto “definisce contesti, scopi e modi di interazione dell’utente, presente nel gruppo di valutazione, con il sito e costruisce scenari d’uso che simulano a livello cognitivo il comportamento dell’utente”.

La simulazione cognitiva dà origine a una serie di giudizi su una scala da 1 a 5, dove 1 rappresenta la mancanza totale di corrispondenza tra gli scopi di partenza e i risultati raggiunti, mentre 5 rappresenta la massima corrispondenza.

Dopo la simulazione cognitiva, segue una verifica sul campo effettuata con utenti disabili, che navigano il sito con le proprie tecnologie assistive. L’esperto raccoglie i loro commenti e studia l’esito della navigazione libera nonché i risultati dell’esecuzione di specifici compiti. Mettendo insieme tutte le osservazioni raccolte, l’esperto redige alla fine un rapporto che contiene un punteggio, in virtù del quale il sito valutato rientrerà in una delle seguenti quattro categorie:

1. valore medio complessivo minore di 2 = assenza di qualità;
2. valore medio complessivo maggiore o uguale a 2 e minore di 3 = primo livello di qualità;
3. valore medio complessivo maggiore o uguale a 3 e minore di 4 = secondo livello di qualità;
4. valore medio complessivo maggiore o uguale a 4 = terzo livello di qualità.

Ciascuno dei tre livelli di qualità dà diritto a esporre, nel logo di accessibilità, un corrispondente numero di asterischi: un asterisco per il primo livello di qualità (Figura 21.1 B), due asterischi per il secondo livello (Figura 21.1 C), tre asterischi per il terzo livello (Figura 21.1 D). Le caratteristiche del logo di accessibilità e i relativi livelli sono descritti nell’allegato E del decreto dell’8 luglio 2005.

L’allegato B definisce, infine, dodici criteri di qualità, in base ai quali l’esperto che si occupa della verifica soggettiva deve giudicare le caratteristiche del sito esaminato. I criteri sono i seguenti:

1. percezione: informazioni e comandi necessari per l’esecuzione dell’attività devono essere sempre disponibili e percettibili;
2. comprensibilità: informazioni e comandi necessari per l’esecuzione delle attività devono essere facili da capire e da usare;
3. operabilità: informazioni e comandi devono consentire una scelta immediata della azione adeguata per raggiungere l’obiettivo voluto;
4. coerenza: simboli, messaggi e azioni devono avere lo stesso significato in tutto l’ambiente;
5. salvaguardia della salute (safety): l’ambiente deve possedere caratteristiche idonee a salvaguardare il benessere psicofisico dell’utente;
6. sicurezza: l’ambiente deve possedere caratteristiche idonee a fornire transazioni e dati affidabili, gestiti con adeguati livelli di sicurezza;
7. trasparenza: l’ambiente deve comunicare all’utente lo stato, gli effetti delle azioni compiute e le informazioni necessarie per la corretta valutazione della dinamica dell’ambiente stesso;
8. apprendibilità: l’ambiente deve possedere caratteristiche di utilizzo di facile e rapido apprendimento;
9. aiuto e documentazione: funzioni di aiuto, quali le guide in linea, e documentazione relativa al funzionamento dell’ambiente devono essere di facile reperimento e connesse al compito svolto dall’utente;
10. tolleranza agli errori: l’ambiente, pur configurandosi in modo da prevenire gli errori, ove questi, comunque, si manifestino, deve fornire appropriati messaggi che individuino chiaramente l’errore occorso e le azioni necessarie per superarlo;
11. gradevolezza: l’ambiente deve possedere caratteristiche idonee a favorire e mantenere l’interesse dell’utente;
12. flessibilità: l’ambiente deve tener conto delle preferenze individuali e dei contesti.

Inizio pagina

I ventidue requisiti per la verifica tecnica

I ventidue requisiti per la verifica tecnica si rifanno, come abbiamo già avuto modo di anticipare, sia alle WCAG 1.0 sia alla Section 508 statunitense. Tali rimandi non hanno un valore normativo, ma servono solo per contestualizzare i requisiti a cui sono associati. Lo precisa il paragrafo 4 (Requisiti di accessibilità per i siti Internet) dell’allegato A del Decreto Ministeriale 8 luglio 2005:

I punti di controllo del W3C-WAI e gli standard della Sezione 508 eventualmente richiamati nei singoli requisiti, sono da intendersi soltanto come elementi di riferimento, al fine di consentire un più facile riscontro con gli standard già impiegati e per facilitare l’utilizzo degli strumenti informatici di valutazione della accessibilità attualmente disponibili sul mercato.

Relazioni tra i requisiti tecnici e le WCAG 1.0

La Tabella 21.1 mostra sinotticamente le relazioni tra i requisiti tecnici della legge italiana e le WCAG 1.0.

Dei 16 punti di controllo di priorità 1 delle WCAG 1.0, i requisiti tecnici ne richiamano 14. Sono esclusi il 4.1 e il 14.1, cioè i due punti di controllo che richiedono di segnalare i cambi di lingua (4.1) e di usare il linguaggio più chiaro e più semplice in relazione all’argomento trattato (14.1).

Tabella 21.1 Punti di controllo delle WCAG 1.0 associati ai requisiti tecnici della legge 4/2004

Requisiti tecnici DM 8 luglio 2005	WCAG 1.0 Level A	WCAG 1.0 Level AA	WCAG 1.0 Level AAA
1		3.1, 3.2, 3.5, 3.6, 3.7, 11.1, 11.2
2	12.1	12.2
3	1.1, 6.2
4	2.1
5	7.1	7.2, 7.3
6		2.2 (per le immagini)	2.2 (per il testo)
7	9.1
8	1.2
9	5.1		5.5, 5.6
10	5.2
11	6.1	3.3
12		3.4
13		5.3, 5.4
14		10.2, 12.4
15	6.3
16		6.4, 9.2, 9.3
17	8.1 (se la funzionalità è importante e non presentata altrove)	8.1 (negli altri casi)
18	1.3, 1.4
19		13.1	13.6
20		7.4, 7.5
21	Non presente	Non presente	Non presente
22	11.4

La scelta di non inserire requisiti tecnici ispirati a questi due punti di controllo ha una ragione ben precisa, analoga a quella che ha ispirato l’equivalente scelta fatta dagli estensori delle linee guida della legge americana sull’accessibilità: il tentativo di limitare ciò che è richiesto agli sviluppatori a quanto può essere verificato e misurato con un sufficiente grado di sicurezza. Per l’esclusione del punto di controllo 4.1 vale però anche un’altra ragione, sulla quale ci siamo soffermati nel Capitolo 7: il fatto, cioè, che la segnalazione dei cambi di lingua in un documento HTML può indurre gli screen reader a comportamenti che sono di danno più che di beneficio per l’accessibilità.

Dei 29 punti di controllo delle WCAG 1.0 che hanno priorità 2, i requisiti tecnici della legge italiana ne richiamano 22, mentre dei 18 di priorità 3 ne sono richiamati soltanto 3. Sono referenziati, infine, entrambi i punti di controllo delle WCAG 1.0 che hanno priorità dipendente dal contesto in cui sono usati (2.2 e 8.1).

L’analisi dei riferimenti alle WCAG 1.0 dimostra, in definitiva, che l’applicazione integrale dei 22 requisiti tecnici definiti nell’Allegato A del decreto 8 luglio 2005 equivale grosso modo alla realizzazione di un sito web accessibile al livello doppia-A delle WCAG 1.0.

Riportiamo di seguito l’elenco completo dei 22 requisiti tecnici, così come appare nell’allegato A del Decreto ministeriale 8 luglio 2005. Il testo di ciascun requisito è accompagnato da un nostro commento, che ne illustra le particolarità e gli eventuali problemi applicativi. Il titolo che segue il numero di ciascun requisito è nostro e non fa parte dell’allegato A del decreto.

Inizio pagina

Requisito 1. Usare linguaggi standardizzati e utilizzarli in modo corretto

Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate nelle versioni più recenti disponibili quando sono supportate dai programmi utente. Utilizzare elementi e attributi in modo conforme alle specifiche, rispettandone l’aspetto semantico. In particolare, per i linguaggi a marcatori HTML (HypertText Markup Language) e XHTML (eXtensible HyperText Markup Language):

1. per tutti i siti di nuova realizzazione utilizzare almeno la versione 4.01 dell’HTML o preferibilmente la versione 1.0 dell’XHTML, in ogni caso con DTD (Document Type Definition - Definizione del Tipo di Documento) di tipo Strict;
2. per i siti esistenti, in sede di prima applicazione, nel caso in cui non sia possibile ottemperare al punto a) è consentito utilizzare la versione dei linguaggi sopra indicati con DTD Transitional, ma con le seguenti avvertenze:
   1. evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi e attributi per definirne le caratteristiche di presentazione della pagina (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico;
   2. evitare la generazione di nuove finestre; ove ciò non fosse possibile, avvisare esplicitamente l’utente del cambiamento del focus;
   3. pianificare la transizione dell’intero sito alla versione con DTD Strict del linguaggio utilizzato, dandone comunicazione alla Presidenza del Consiglio dei Ministri – Dipartimento per l’innovazione e le tecnologie e al Centro nazionale per l’informatica nella pubblica amministrazione.

Il requisito tecnico numero 1 è sicuramente quello che crea a sviluppatori e a redattori di contenuti i maggiori problemi applicativi. La richiesta di Utilizzare elementi e attributi in modo conforme alle specifiche, rispettandone l’aspetto semantico implica, infatti, secondo l’interpretazione più stringente, la produzione di codice di marcatura a zero errori. Anche un errore veniale è sufficiente a violare la sintassi di un linguaggio di marcatura: basta, per esempio, che il nome di un attributo, in un documento XHTML, appaia in caratteri maiuscoli o che il suo valore non sia circondato da apici, perché vi sia una violazione delle regole definite dalle specifiche del linguaggio XHTML. Di conseguenza, ottenere zero errori dall’analisi dei validatori automatici è il modo più semplice per dimostrare di aver usato elementi e attributi in modo conforme alle specifiche del linguaggio di marcatura adoperato.

In realtà, non c’è nulla di più facile che incorrere in pagine HTML e XHTML contenenti errori veniali: le pagine web a zero errori sono ancora oggi l’eccezione, non la regola. Ciò espone i gestori di siti che dichiarano la conformità alla legge 4/2004 al rischio continuo di non essere realmente conformi, per la violazione del requisito 1. Per evitare tale rischio, servirebbero CMS, cioè sistemi per la gestione automatica di siti web, in grado di non pubblicare neppure una virgola senza che sia osservata strettamente la sintassi del linguaggio di marcatura prescelto. Ma poiché, al momento, la stragrande maggioranza dei siti web usa CMS non conformi alle richieste della legge 4/2004, e cambiare il CMS in siti complessi e di grandi dimensioni è un’impresa costosa e di difficile realizzazione, ne consegue che la violazione del requisito 1 è un fenomeno quasi universale, che coinvolge anche i siti che hanno perseguito con impegno il tentativo di applicare i ventidue requisiti tecnici.

Un secondo elemento critico per la conformità al requisito 1 è l’obbligo di usare le DTD strict di HTML 4.01 e di XHTML 1.0. Questa richiesta è perfettamente in linea con le esigenze dell’accessibilità (si veda in proposito il commento al punto di controllo 3.2 delle WCAG 1.0, nel Capitolo 6). Tuttavia conduce facilmente alla perdita della conformità: basta, infatti, che una pagina web incorpori brani di codice ereditati da documenti datati, per ritrovare con ogni probabilità al suo interno una serie di elementi e attributi non previsti dalla DTD strict (per esempio gli elementi CENTER e FONT). In altre parole, l’adeguamento di un sito alla DTD strict di HTML 4.01 o di XHTML 1.0 richiede innanzitutto un controllo accurato del codice di marcatura delle pagine preesistenti, allo scopo di rimuovere o modificare tutti i contenuti marcati in modi che violano le due DTD.

Inizio pagina

Requisito 2. Non è consentito l’uso dei frame

Non è consentito l’uso dei frame nella realizzazione di nuovi siti. In sede di prima applicazione, per i siti Web esistenti già realizzati con frame è consentito l’uso di HTML 4.01 o XHTML 1.0 con DTD frameset, ma con le seguenti avvertenze:

1. evitare di utilizzare, all’interno del linguaggio a marcatori con il quale la pagina è realizzata, elementi e attributi per definirne le caratteristiche di presentazione della pagina (per esempio, caratteristiche dei caratteri del testo, colori del testo stesso e dello sfondo ecc.), ricorrendo invece ai Fogli di Stile CSS (Cascading Style Sheets) per ottenere lo stesso effetto grafico;
2. fare in modo che ogni frame abbia un titolo significativo per facilitarne l’identificazione e la navigazione; se necessario, descrivere anche lo scopo dei frame e la loro relazione;
3. pianificare la transizione a XHTML almeno nella versione 1.0 con DTD Strict dell’intero sito dandone comunicazione alla Presidenza del Consiglio dei Ministri – Dipartimento per l’innovazione e le tecnologie e al Centro nazionale per l’informatica nella pubblica amministrazione.

Il requisito 2 richiede che i siti di nuova realizzazione siano concepiti senza ricorrere all’obsoleto meccanismo dei frame (il divieto del resto era già implicito nella richiesta del requisito 1 di realizzare pagine web con DTD strict, non compatibile con l’uso dei frame).

Come già per il requisito 1, è disponibile però l’alternativa della “prima applicazione”: per i siti esistenti già realizzati a frame, è lecito mantenere l’architettura esistente, purché i frame abbiano nomi e descrizioni significativi e purché le singole pagine che costituiscono il frameset siano gestite in modo da non utilizzare elementi e attributi di presentazione.

Va sottolineato, però, che in una struttura a frame, le singole pagine devono avere la DTD transitional, altrimenti non possono usare l’attributo target, senza il quale non è possibile creare collegamenti la cui destinazione sia in un frame differente. L’uso di un’architettura a frame impedisce, pertanto, anche di rispettare il requisito 1, nella parte in cui prescrive l’uso delle DTD strict.

Inizio pagina

Requisito 3. Fornire equivalenti testuali per tutti gli oggetti non di testo

Fornire una alternativa testuale equivalente per ogni oggetto non di testo presente in una pagina e garantire che quando il contenuto non testuale di un oggetto cambia dinamicamente vengano aggiornati anche i relativi contenuti equivalenti predisposti; l’alternativa testuale equivalente di un oggetto non testuale deve essere commisurata alla funzione esercitata dall’oggetto originale nello specifico contesto.

Il requisito 3 sintetizza le richieste dei punti di controllo 1.1 e 6.2 delle WCAG 1.0, entrambi di priorità 1. In pratica, richiede alternative testuali non solo per i contenuti non testuali statici, come possono essere le immagini che accompagnano il testo di un articolo, ma anche per i contenuti non testuali dinamici, come gli oggetti di programmazione Java o Flash.

Il testo di questo requisito, nella parte in cui tratta degli equivalenti dinamici, soffre della medesima ambiguità che era già presente nel punto di controllo 6.2 delle WCAG 1.0, a cui è ispirato (si veda in proposito il Capitolo 9). Bisogna intendere, cioè, l’aggiornamento degli equivalenti testuali come riferito ai testi alternativi inseriti nel codice di marcatura (per esempio come valori di alt o contenuto di OBJECT), che cambiano quando cambia l’intero oggetto dinamico a cui sono associati, piuttosto che come riferito a ipotetici testi alternativi dinamici, inseriti all’interno degli stessi oggetti di programmazione, come pure si potrebbe intendere.

La parte finale dell’enunciato del requisito, infine, fa riferimento alla funzione che gli oggetti non testuali svolgono all’interno di un documento, richiedendo di adeguare i relativi equivalenti testuali alla loro importanza all’interno del documento. Se si tratta, per esempio, di oggetti grafici puramente decorativi, è consigliabile inserire un attributo alt vuoto, in modo da non appesantire la lettura dei sintetizzatori vocali con informazioni ridondanti.

Per una trattazione dettagliata dei modi di applicare il requisito 3, si faccia riferimento ai commenti ai punti di controllo 1.1 e 6.2 delle WCAG 1.0, rispettivamente nei Capitoli 4 e 9 di questo libro.

Inizio pagina

Requisito 4. Non vincolare informazioni e funzionalità alla possibilità di percepire i colori

Garantire che tutti gli elementi informativi e tutte le funzionalità siano disponibili anche in assenza del particolare colore utilizzato per presentarli nella pagina.

Il requisito 4 ricalca strettamente il contenuto del punto di controllo 2.1 delle WCAG 1.0 (Garantire che tutte le informazioni veicolate con il colore siano disponibili anche senza colore, per esempio attraverso il contesto o il codice di marcatura). Per la sua applicazione, si faccia riferimento al commento al punto di controllo 2.1, nella prima parte del Capitolo 5.

Inizio pagina

Requisito 5. Evitare contenuti che possono scatenare attacchi o disturbare la concentrazione

Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di intermittenza possano provocare disturbi da epilessia fotosensibile o disturbi della concentrazione, ovvero possano causare il malfunzionamento delle tecnologie assistive utilizzate; qualora esigenze informative richiedano comunque il loro utilizzo, avvertire l’utente del possibile rischio prima di presentarli e predisporre metodi che consentano di evitare tali elementi.

Il requisito 5 somma le prescrizioni dei punti di controllo 7.1, 7.2 e 7.3 delle WCAG 1.0. Si faccia riferimento al Capitolo 10, per informazioni dettagliate sui tre punti di controllo referenziati dal requisito 5.

C’è da notare, però, una differenza netta tra le WCAG 1.0 e il requisito tecnico della legge italiana. Mentre i tre punti di controllo citati dicono semplicemente di evitare l’uso di contenuti sfarfallanti, lampeggianti e in movimento (finché i programmi utente non forniranno strumenti adeguati di controllo), il requisito 5 fornisce un’alternativa: inserire ugualmente i contenuti pericolosi, avendo cura di avvertire l’utente del rischio a cui va incontro e fornendo meccanismi per saltarli.

Inizio pagina

Requisito 6. Garantire che le informazioni visive e acustiche siano chiaramente distinguibili dallo sfondo

Garantire che siano sempre distinguibili il contenuto informativo (foreground) e lo sfondo (background), ricorrendo a un sufficiente contrasto (nel caso del testo) o a differenti livelli sonori (in caso di parlato con sottofondo musicale); evitare di presentare testi in forma di immagini; ove non sia possibile, ricorrere agli stessi criteri di distinguibilità indicati in precedenza.

Il requisito 6 richiama le richieste del punto di controllo 2.2 delle WCAG 1.0. Per informazioni e modalità applicative, si faccia riferimento al commento a questo punto di controllo nel Capitolo 5. Il calcolo delle differenze di contrasto tra primo piano e sfondo va fatto mediante il medesimo algoritmo dei colori presentato e analizzato nello stesso Capitolo 5.

Il requisito 6 introduce però due differenze rispetto al punto di controllo 2.2. Innanzitutto, estende la richiesta di un sufficiente contrasto tra primo piano e sfondo anche ai contenuti audio (pur non fornendo un metodo per calcolare tale differenza): in ciò anticipa le WCAG 2.0, che, tramite un apposito criterio di successo, l’1.4.6, richiedono che i suoni di sfondo non interferiscano col parlato (ma le WCAG 2.0, a differenza del requisito 6 della legge italiana, forniscono anche un criterio tecnico di valutazione, indicando in almeno 20 decibel la differenza tra i suoni in primo piano e i suoni di sfondo).

La seconda differenza è la richiesta di non presentare testi in forma di immagini, che è assente dalle WCAG 1.0. Viene tuttavia lasciata agli sviluppatori la facoltà di continuare a usare i testi in forma di immagini (ove non sia possibile evitarli), purché superino le stesse soglie di contrasto definite per il testo.

Requisito 7. Utilizzare mappe immagine lato client piuttosto che lato server

Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato server, salvo il caso in cui le zone sensibili non possano essere definite con una delle forme geometriche predefinite indicate nella DTD adottata.

Il requisito riprende più o meno letteralmente il punto di controllo 9.1 delle WCAG 1.0, compreso il riferimento alla possibilità di usare mappe immagine lato server, nel caso in cui la forma geometrica dell’area sensibile non sia realizzabile per mezzo di una mappa immagine lato client.

Per maggiori informazioni sull’argomento del requisito 7, si veda il commento al punto di controllo 9.1 nel Capitolo 14.

Inizio pagina

Requisito 8. Nel caso di mappe immagine lato server, fornire collegamenti testuali alternativi

In caso di utilizzo di mappe immagine lato server, fornire i collegamenti di testo alternativi necessari per ottenere tutte le informazioni o i servizi raggiungibili interagendo direttamente con la mappa.

Il requisito 8 richiama il punto di controllo 1.2 delle WCAG 1.0. La ragione per cui devono essere forniti collegamenti di testo alternativi, in caso di utilizzo di mappe immagine lato server, sta nel fatto che l’input, per queste ultime, è dipendente da strumenti di puntamento come il mouse e non può essere validamente emulato da tastiera. Si veda in proposito il commento al punto di controllo 1.2 nel Capitolo 4.

Inizio pagina

Requisito 9. Per le tabelle di dati, descrivere i contenuti e identificare le celle d’intestazione

Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti dalla DTD adottata per descrivere i contenuti e identificare le intestazioni di righe e colonne.

Il requisito 9 sintetizza le prescrizioni dei punti di controllo 5.1, 5.5 e 5.6 delle WCAG 1.0, per maggiori dettagli sui quali rimandiamo ai relativi commenti contenuti nel Capitolo 8.

Vista la derivazione da quei tre punti di controllo, possiamo tradurre in istruzioni più semplici e dirette il linguaggio un po’ astruso con cui è formulato questo requisito:

1. usare l’elemento TH per marcare le celle d’intestazione (punto di controllo 5.1 delle WCAG 1.0);
2. usare l’attributo summary per descrivere il contenuto di una tabella di dati a beneficio di chi naviga con uno screen reader (punto di controllo 5.5);
3. usare l’attributo abbr per fornire abbreviazioni, nel caso che le celle d’intestazione contengano testi troppo lunghi (punto di controllo 5.6).

Inizio pagina

Requisito 10. Per le tabelle di dati, associare le celle di dati alle rispettive celle d’intestazione

Per le tabelle dati usare gli elementi (marcatori) e gli attributi previsti nella DTD adottata per associare le celle di dati e le celle di intestazione che hanno due o più livelli logici di intestazione di righe o colonne.

Il requisito 10 riprende il punto di controllo 5.2 delle WCAG 1.0, ma è formulato in modo così ingarbugliato che, senza andare a leggere cosa dice il relativo punto di controllo delle WCAG, anche uno sviluppatore esperto rischia di non capire nulla.

Andiamo a rileggere, dunque, tradotto in italiano, il testo del punto di controllo 5.2: Per le tabelle di dati che hanno due o più livelli logici di intestazioni di riga o di colonna, usare la marcatura per associare celle di dati e celle d’intestazione (For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells).

Nel testo del punto di controllo, sono le tabelle – ed è comprensibile – ad avere due o più livelli logici di intestazioni di riga o di colonna. Nel nostro requisito, invece, sono le celle di dati e le celle di intestazione che hanno due o più livelli logici di intestazione di righe o colonne. Ci permettiamo di affermare che una simile formulazione è a dir poco confusa, per non dire incomprensibile: le singole celle – siano esse di dati o di intestazione – al massimo dipendono da altre celle, ma non hanno “due o più livelli logici di intestazione di righe o colonne”: tutto ciò che possono avere è un contenuto. È sorprendente che il requisito 10 sia giunto in questa forma fino all’approvazione definitiva e alla pubblicazione sulla Gazzetta Ufficiale, senza che nessuno dei revisori si sia accorto dell’errore.

Riportando, quindi, il requisito alla formulazione e alle intenzioni proprie del punto di controllo 5.2 delle WCAG 1.0, esso richiede agli sviluppatori due tipi di intervento:

• raggruppare i blocchi logici delle tabelle di dati complesse, usando gli appositi elementi per i raggruppamenti orizzontali (THEAD, TBODY, TFOOT) e verticali (COL e COLGROUP);
• associare tra loro opportunamente celle di dati e celle d’intestazione per mezzo degli attribuiti scope, axis, headers e id, allo scopo di favorire la comprensione delle relazioni tra i dati agli utenti di screen reader.

Per un esempio del primo tipo di intervento, si veda il paragrafo Uso di CAPTION e dei raggruppamenti di righe e colonne nel Capitolo 17. Per un esempio del secondo tipo di intervento, si veda invece il commento al punto di controllo 5.2 nel Capitolo 8.

Inizio pagina

Requisito 11. Usare i fogli di stile per controllare la presentazione

Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le pagine in modo che possano essere lette anche quando i fogli di stile siano disabilitati o non supportati.

Il requisito 11 rappresenta la somma dei punti di controllo 3.3 e 6.1 delle WCAG 1.0. La sua applicazione è particolarmente importante per l’accessibilità, perché una buona separazione di contenuto e presentazione, gestita appunto attraverso l’uso dei CSS, permette di avere documenti che possono essere fruiti con successo attraverso i più diversi dispositivi.

Per maggiori informazioni sui concetti richiamati da questo requisito, si vedano i commenti al punto di controllo 3.3 nel Capitolo 6 e al punto di controllo 6.1 nel Capitolo 9.

Inizio pagina

Requisito 12. Fare in modo che i contenuti rimangano fruibili anche in caso di ridimensionamento

La presentazione e i contenuti testuali di una pagina devono potersi adattare alle dimensioni della finestra del browser utilizzata dall’utente senza sovrapposizione degli oggetti presenti o perdita di informazioni tali da rendere incomprensibile il contenuto, anche in caso di ridimensionamento, ingrandimento o riduzione dell’area di visualizzazione o dei caratteri rispetto ai valori predefiniti di tali parametri.

Il requisito 12 richiama il punto di controllo 3.4 delle WCAG 1.0, ma ha un enunciato molto differente e più complesso. Mentre il punto di controllo 3.4 si limita a raccomandare l’uso di unità relative come gli em (invece di unità assolute come i pt e i cm) nei valori di attributo e nei valori di proprietà dei fogli di stile, il requisito 12 precisa il risultato che l’adozione delle unità relative serve a garantire, cioè la capacità dei contenuti di ridisporsi, adattandosi al variare delle dimensioni della finestra del browser.

Il testo del requisito avverte, inoltre, che non devono verificarsi sovrapposizioni di contenuti, tali da generare perdita di informazioni, se l’utente ingrandisce o rimpicciolisce la finestra del browser e/o la dimensione dei caratteri.

Il requisito 12 ci sembra raccomandare, in sostanza, di adottare un layout liquido, cioè quel tipo d’impaginazione in cui i contenuti si adattano automaticamente alla dimensione orizzontale della finestra del browser, ma trascura purtroppo di fornire dei limiti per il ridimensionamento. Nessuna struttura grafica, infatti, per quanto ben progettata, può garantire l’indefinita conservazione della leggibilità dei contenuti, per qualsiasi larghezza della finestra del browser e per qualsiasi fattore d’ingrandimento o di riduzione dei caratteri. Di solito il 200% e il 50% della grandezza-base dei caratteri sono limiti oltre i quali la leggibilità dei contenuti risulta gravemente compromessa, anche per chi ha una vista nella media e non usa ingranditori di schermo.

Di ciò tengono conto, per esempio, le WCAG 2.0, che, nel criterio di successo 1.4.4 (si veda in proposito il Capitolo 20), specificano che Il testo riprodotto visualmente può essere ingrandito fino al 200 per cento e rimpicciolito fino al 50 per cento senza il ricorso a tecnologie assistive e senza perdite di contenuto o di funzionalità. Il criterio di successo 1.4.7 aggiunge poi alla precedente formulazione il vincolo di evitare la comparsa della barra di scorrimento orizzontale.

Purtroppo, in mancanza di analoghe precisazioni sui limiti dell’adattabilità dei contenuti, non esistono criteri certi per valutare la corretta applicazione del requisito 12 della legge italiana. In liste e forum dedicati all’accessibilità, è passato il messaggio che il requisito 12 è rispettato se non vi è sovrapposizione dei contenuti né perdita di informazioni quando la pagina è caricata in Internet Explorer alla risoluzione di 800×600, con i caratteri impostati alla massima dimensione (voce di menu Molto grandi). Tuttavia, non esiste nessun documento ufficiale del CNIPA, del Governo o del Ministro competente che avvalori questa determinazione.

Inizio pagina

Requisito 13. Garantire che i contenuti delle tabelle d’impaginazione siano comprensibili anche quando linearizzati

In caso di utilizzo di tabelle a scopo di impaginazione, garantire che il contenuto della tabella sia comprensibile anche quando questa viene letta in modo linearizzato e utilizzare gli elementi e gli attributi di una tabella rispettandone il valore semantico definito nella specifica del linguaggio a marcatori utilizzato.

I punti di controllo 5.3 e 5.4 delle WCAG 1.0 sono la fonte d’ispirazione del requisito 13 (per informazioni dettagliate sul modo di applicarli, si consulti il Capitolo 8).

La prima parte del requisito ricalca il senso generale del punto di controllo 5.3.

La seconda parte del requisito, invece, usa una formula molto astratta, per intendere il medesimo concetto che esprime, in modo più chiaro e diretto, il punto di controllo 5.4 (Se una tabella è usata a scopo d’impaginazione, non usare alcuna marcatura strutturale per ottenere effetti di formattazione visuale).

In pratica, l’espressione alla fine del requisito 13, utilizzare gli elementi e gli attributi di una tabella rispettandone il valore semantico, allude alla raccomandazione di non usare TH e altri elementi strutturali propri delle tabelle di dati al solo scopo di ottenere effetti di formattazione, quali il grassetto e l’allineamento al centro: ciò per non indurre in confusione gli utenti di screen reader, per i quali gli elementi strutturali indicano delle relazioni logiche, che un puro effetto di formattazione potrebbe non implicare.

Infine, a voler essere pignoli, il requisito 13 presenta una mancanza di coerenza sia internamente sia rispetto al requisito 1. Quest’ultimo, infatti, richiede di usare elementi e attributi dei linguaggi di marcatura in base al loro valore semantico, così come è definito dalle specifiche: la stessa cosa che richiede anche la parte finale del requisito 13, relativamente al codice di marcatura delle tabelle. Tuttavia, usare una tabella a scopo di impaginazione, non quindi per incasellare dati realmente tabellari, è già in partenza una violazione della richiesta di usare l’elemento TABLE secondo il significato che gli attribuiscono le specifiche W3C.

Il capitolo delle Specifiche HTML 4.01 dedicato alle tabelle è molto chiaro in proposito: sconsiglia espressamente di usare le tabelle per arrangiare visivamente i contenuti e contiene esempi realizzati con sole tabelle di dati. Insomma, le tabelle d’impaginazione, layout tables in inglese, rappresentano secondo le Specifiche HTML 4.01, un uso improprio dell’elemento TABLE e degli altri elementi che da esso dipendono. Non si vede, pertanto, come possano gli elementi di tabella essere usati in accordo con il valore semantico che gli è attribuito dalle Specifiche medesime, se vengono adoperati per creare tabelle d’impaginazione.

Inizio pagina

Requisito 14. Etichettare i campi modulo in modo da favorire le tecnologie assistive

Nei moduli (form), associare in maniera esplicita le etichette ai rispettivi controlli, posizionandole in modo che sia agevolata la compilazione dei campi da parte di chi utilizza le tecnologie assistive.

I riferimenti per questo requisito sono i punti di controllo 10.2 e 12.4 delle WCAG 1.0. Per informazioni e dettagli applicativi, si vedano i commenti ai due punti di controllo, rispettivamente nel Capitolo 15 e nel Capitolo 17.

A commento del requisito 14, bisogna segnalare che il suo testo fonde le raccomandazioni dei due punti di controllo da cui è stato derivato. Infatti, le WCAG richiedono un posizionamento particolare delle etichette, rispetto ai campi modulo a cui sono associate, solo nel caso di associazione implicita, cioè quando il controllo di modulo è incorporato all’interno dell’elemento LABEL, senza null’altro che la vicinanza a porli in relazione.

È appunto questa la fattispecie regolata dal punto di controllo 10.2 delle WCAG 1.0, che dice:

(...) per tutti i controlli di modulo che hanno etichette associate in modo implicito, garantire che l’etichetta sia posizionata correttamente.

E subito dopo spiega:

L’etichetta deve precedere immediatamente il suo controllo sulla medesima riga (essendo permesso di avere più di un controllo/etichetta per riga) o deve trovarsi nella riga immediatamente precedente il controllo (con una sola etichetta e un solo controllo per riga).

Invece, l’associazione esplicita tra etichette e controlli, che si fa usando l’attributo for nell’elemento LABEL e l’attributo id nel controllo associato, entrambi con il medesimo valore, non richiede che etichetta e controllo siano posizionati l’una vicina all’altro. Teoricamente, è possibile posizionare l’etichetta in un punto qualsiasi della pagina, anche lontanissimo dal controllo associato, purché l’associazione tra etichetta e controllo a livello di codice sia inequivocabile. Inoltre, è lecito associare più etichette a un medesimo controllo, indipendentemente dalla loro posizione, usando per ciascuna di esse il medesimo valore dell’attributo for, corrispondente al valore di id del controllo associato.

Tuttavia, nella pratica, le etichette – non importa se associate implicitamente o esplicitamente ai relativi controlli di modulo – devono essere posizionate vicino ai medesimi, perché nella fase di compilazione gli screen reader leggono etichette e controlli nella sequenza in cui si trovano nel codice o, al massimo, nella sequenza definita per mezzo dell’attributo tabindex, anche se le associazioni realizzate per mezzo di LABEL, id e for richiederebbero sequenze differenti. In considerazione di ciò, il requisito 14 fa una richiesta corretta, anche se non giustificabile dal punto di vista del codice di marcatura (l’associazione esplicita tra etichette e controlli di modulo dovrebbe servire proprio per creare un vincolo indipendente dal posizionamento).

Inizio pagina

Requisito 15. Garantire che le pagine siano utilizzabili anche quando non c’è supporto per script e oggetti incorporati

Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati; ove ciò non sia possibile fornire una spiegazione testuale della funzionalità svolta e garantire una alternativa testuale equivalente, in modo analogo a quanto indicato nel requisito n. 3.

Il requisito 15 richiama quasi letteralmente il testo del punto di controllo 6.3 delle WCAG 1.0, che è a nostro parere uno dei più ambigui della Raccomandazione W3C (si veda in proposito il commento al punto di controllo 6.3 nel Capitolo 9).

Il requisito 15 aggiunge un ulteriore carico a tale ambiguità: nel caso di pagine giudicate non utilizzabili in mancanza di supporto per script e oggetti di programmazione, richiede, infatti, una spiegazione testuale della funzionalità svolta dallo script o dall’oggetto di programmazione non supportati, in aggiunta a un’alternativa testuale equivalente. Sembra, in altre parole, che si debba descrivere sia che cosa fanno (cioè la funzionalità) sia quali contenuti generano (ecco l’alternativa equivalente) lo script o l’oggetto di programmazione non supportati.

Immaginiamo una pagina web che contenga un oggetto Flash dalle complesse funzionalità. Cosa deve fare lo sviluppatore che voglia applicare scrupolosamente il requisito 15? Deve descrivere pedantemente ogni singola funzionalità presente nell’oggetto Flash (moduli, menu ecc.)? O è sufficiente una generica descrizione di cosa fa l’applicazione nel suo complesso? E in che modo può essere fornita, poi, un’alternativa testuale statica per un oggetto dinamico, i cui contenuti possono cambiare in seguito all’interazione con l’utente? Sinceramente non lo sappiamo e ci sembra, in generale, molto difficile distinguere tra spiegazione della funzionalità e alternativa equivalente.

Purtroppo l’allegato A del decreto 8 luglio 2005 non fornisce in proposito alcun chiarimento. Si limita, infatti, a definire le regole, cioè il testo dei requisiti tecnici così come lo riportiamo in questo capitolo, senza aggiungere alcun esempio applicativo. Pertanto, l’unico ausilio a cui si può fare riferimento, in questo come in altri casi, sono i laconici rimandi alle WCAG 1.0 e alla Section 508 statunitense.

Inizio pagina

Requisito 16. Rendere i gestori di eventi indipendenti dal dispositivo di input

Garantire che i gestori di eventi che attivano script, applet o altri oggetti di programmazione o che possiedono una propria specifica interfaccia, siano indipendenti da uno specifico dispositivo di input.

Sono tre i punti di controllo delle WCAG 1.0 referenziati dal requisito 16: il 6.4, il 9.2 e il 9.3. Per capire come applicare il requisito, è utile rileggere che cosa ciascuno di essi raccomanda:

6.4. Per script e applet, garantire che i gestori di eventi siano indipendenti dal dispositivo di input;

9.2. Garantire che ogni elemento dotato di una sua propria interfaccia possa essere utilizzato in modo indipendente dal dispositivo;

9.3. Per gli script, specificare gestori di evento logici piuttosto che dipendenti dal dispositivo.

Rimandiamo, per informazioni sulle modalità di applicazione, ai commenti a ciascuno dei tre punti di controllo, e precisamente, per il punto di controllo 6.4 al Capitolo 9 e, per i punti di controllo 9.2 e 9.3, al Capitolo 14.

Inizio pagina

Requisito 17. Rendere direttamente accessibili i contenuti generati da script e oggetti di programmazione

Garantire che le funzionalità e le informazioni veicolate per mezzo di oggetti di programmazione, oggetti che utilizzano tecnologie non definite da grammatiche formali pubblicate, script e applet siano direttamente accessibili.

Il requisito 17 ha un unico riferimento, il punto di controllo 8.1 delle WCAG 1.0, che raccomanda di “Rendere gli elementi di programmazione come script e applet direttamente accessibili o compatibili con le tecnologie assistive”.

La materia coperta dal punto di controllo 8.1, e di conseguenza dal requisito 17 della normativa italiana, è estremamente vasta e copre qualsiasi interfaccia incorporata in una pagina web, da quelle realizzate in JavaScript a quelle basate su oggetti Java, Flash, PDF ecc., sia gestibili direttamente attraverso le funzionalità del browser sia per mezzo di plug-in da installare a parte.

Abbiamo dedicato all’accessibilità di JavaScript, Flash e PDF tre capitoli del libro, l’11 il 12 e il 13, ai quali rimandiamo per i necessari approfondimenti sulle modalità di soddisfare la richiesta del requisito 17.

Inizio pagina

Requisito 18. Corredare i contenuti multimediali di adeguati equivalenti (sottotitoli, audiodescrizioni, trascrizioni)

Nel caso in cui un filmato o una presentazione multimediale siano indispensabili per la completezza dell’informazione fornita o del servizio erogato, predisporre una alternativa testuale equivalente, sincronizzata in forma di sotto-titolazione o di descrizione vocale, oppure fornire un riassunto o una semplice etichetta per ciascun elemento video o multimediale tenendo conto del livello di importanza e delle difficoltà di realizzazione nel caso di trasmissioni in tempo reale.

Il complesso enunciato del requisito 18 assomma le prescrizioni dei punti di controllo 1.3 e 1.4 delle WCAG 1.0. Riportiamo, per confronto, il testo dei due punti di controllo:

1.3. Finché i programmi utente non saranno in grado di leggere ad alta voce l’equivalente testuale di una traccia video, fornire un’audiodescrizione delle informazioni importanti presenti nella traccia video di una presentazione multimediale.

1.4. Per ogni presentazione multimediale temporizzata (per esempio: un filmato o un’animazione), sincronizzare le alternative equivalenti (per esempio: sottotitoli o audiodescrizioni della traccia video) con la presentazione.

Purtroppo, come capita anche in altri casi, l’enunciato del requisito 18 fa sorgere dei dubbi applicativi.

Innanzitutto, il modo in cui è formulato il testo (predisporre una alternativa testuale equivalente, sincronizzata in forma di sotto-titolazione o di descrizione vocale) fa pensare che i sottotitoli e l’audiodescrizione siano due modi tra loro alternativi di soddisfare il requisito. In realtà non è così. Audiodescrizione e sottotitoli sono la risposta a due disabilità differenti: la prima serve per chi non può vedere l’ambientazione della presentazione multimediale, mentre i secondi servono per chi non può ascoltare i dialoghi e i suoni. Dunque, dovrebbero essere implementati entrambi, sottotitoli e audiodescrizione, se si vuole avere un’accessibilità completa.

In secondo luogo, la seconda parte del requisito, quella che comincia con oppure fornire un riassunto, lascia a nostro parere troppa discrezionalità ad autori e sviluppatori, che possono in quelle parole trovare la pezza d’appoggio per limitare il proprio intervento a riassunti ed etichette, in luogo delle più faticose sottotitolazioni e audiodescrizioni.

Per una trattazione approfondita dell’accessibilità dei contenuti multimediali, e in particolare dei modi di compensare le differenti disabilità, rimandiamo i lettori alle varie tecniche applicative che abbiamo illustrato nel Capitolo 4, a commento dei punti di controllo 1.3 e 1.4 delle WCAG 1.0.

Inizio pagina

Requisito 19. Rendere chiara la destinazione dei collegamenti e predisporre meccanismi di salto per i contenuti ripetitivi

Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi significativi anche se letti indipendentemente dal proprio contesto oppure associare ai collegamenti testi alternativi che possiedano analoghe caratteristiche esplicative, nonché prevedere meccanismi che consentano di evitare la lettura ripetitiva di sequenze di collegamenti comuni a più pagine.

I riferimenti del requisito 19 alle WCAG 1.0 sono i punti di controllo 13.1, che richiede di Identificare chiaramente la destinazione di ogni collegamento, e 13.6, che raccomanda di Raggruppare i collegamenti correlati, identificare il gruppo (per i programmi utente), e, finché non lo faranno i programmi utente, fornire un modo per saltare il gruppo.

Per tutte le informazioni applicative del caso, rimandiamo ai commenti ai punti di controllo 13.1 e 13.6 nel Capitolo 18.

Inizio pagina

Requisito 20. In caso di contenuti temporizzati, avvisare l’utente circa i limiti di tempo e le alternative disponibili

Nel caso che per la fruizione del servizio erogato in una pagina è previsto un intervallo di tempo predefinito entro il quale eseguire determinate azioni, è necessario avvisare esplicitamente l’utente, indicando il tempo massimo consentito e le alternative per fruire del servizio stesso.

I riferimenti del requisito 20 sono i punti di controllo 7.4 e 7.5 delle WCAG 1.0, che affermano:

7.4. Finché i programmi utente non forniranno la possibilità di bloccare l’aggiornamento, non creare pagine che si autoaggiornano periodicamente.

7.5. Finché i programmi utente non renderanno possibile bloccare il reindirizzamento automatico, non usare codice di marcatura per reindirizzare automaticamente le pagine. Configurare, invece, il server affinché esegua il reindirizzamento.

Per informazioni sulle modalità applicative, si vedano i commenti ai due punti di controllo, nel Capitolo 10.

Il confronto con l’enunciato del requisito 20 permette, però, di riscontrare delle differenze non secondarie. I due punti di controllo citati richiedono, con la solita formula provvisoria tipica delle WCAG 1.0 (Until user agents...), di evitare l’autoaggiornamento e il reindirizzamento automatici, generati attraverso il codice di marcatura. Il requisito 21 non richiede, invece, di evitare le funzioni temporizzate, ma soltanto di avvisare esplicitamente l’utente dei limiti di tempo e delle alternative disponibili.

Inoltre, il modo in cui è espresso il requisito 20 allarga la sua sfera di applicazione a qualsiasi funzione temporizzata (per esempio un’attività di test basata su domande e risposte da fornire entro un dato tempo, un gioco basato su un’interfaccia utente incorporata ecc.): ben oltre, cioè, i limiti dell’autoaggiornamento o del reindirizzamento automatici di pagine HTML, che sono gli oggetti dei punti di controllo 7.4 e 7.5 delle WCAG 1.0.

Ci pare, in conclusione, che il requisito 20 mostri più affinità con il criterio di successo 2.2.1 delle WCAG 2.0 piuttosto che con i citati punti di controllo delle WCAG 1.0. In particolare, mostra affinità con la condizione “Estensione” del criterio di successo 2.2.1 (si veda il Capitolo 20 per il testo completo del criterio di successo):

Estensione. L’utente riceve un avviso prima che il tempo si esaurisca e gli vengono dati almeno 20 secondi per estendere il limite di tempo tramite un’azione semplice (per esempio, “premere un tasto qualunque”), e all’utente è concesso di estendere il limite di tempo per almeno dieci volte.

Inizio pagina

Requisito 21. Rendere i comandi attivabili da tastiera e le loro etichette ben visibili e sufficientemente distanziate

Rendere selezionabili e attivabili tramite comandi da tastiere o tecnologie in emulazione di tastiera o tramite sistemi di puntamento diversi dal mouse i collegamenti presenti in una pagina; per facilitare la selezione e l’attivazione dei collegamenti presenti in una pagina è necessario garantire che la distanza verticale di liste di link e la spaziatura orizzontale tra link consecutivi sia di almeno 0,5 em, le distanze orizzontale e verticale tra i pulsanti di un modulo sia di almeno 0,5 em e che le dimensioni dei pulsanti in un modulo siano tali da rendere chiaramente leggibile l’etichetta in essi contenuta.

Il requisito 21 è l’unico che non fornisce riferimenti né alle WCAG 1.0 né alle linee guida della Section 508 e rappresenta, pertanto, un contributo originale per l’accessibilità.

Ci sembra, tuttavia, che la prima parte dell’enunciato, quella che richiede di rendere i collegamenti selezionabili e attivabili da tastiera, abbia qualche elemento di contatto con i punti di controllo 9.4 e 9.5 delle WCAG 1.0, che richiedono, rispettivamente, di Creare un ordine di tabulazione logico attraverso link, controlli di modulo e oggetti (9.4) e di Fornire scorciatoie da tastiera per i collegamenti importanti (...), controlli di modulo e gruppi di controlli di modulo (9.5).

A parte queste possibili analogie, affinché i collegamenti siano selezionabili da tastiera è opportuno evitare “trappole” generate da script, che blocchino la navigazione da tastiera (il meccanismo è spiegato nel commento al punto di controllo 6.4 delle WCAG 1.0, nel Capitolo 9).

È importante, anche, impostare degli effetti di attivazione che rendano i collegamenti che ricevono il focus ben visibili e distinguibili dal contesto (si veda l’esempio nel Listato 5.1).

In linea generale, tutti i collegamenti sono comunque normalmente attivabili da tastiera, in qualsiasi browser. Il requisito 21 mira, piuttosto, a definire criteri per ottenere una buona leggibilità di collegamenti e pulsanti e una distanza sufficiente tra essi (per consentire, per esempio, ai disabili motori di selezionarli e attivarli senza troppa fatica).

Richiede, perciò, che le dimensioni dei pulsanti siano sufficientemente grandi da permettere di leggerne l’etichetta, anche se non specifica misure di soglia per la dimensione delle etichette.

Dove le misure di soglia sono specificate, ed è l’unico caso nei 22 requisiti tecnici, è per la distanza orizzontale e verticale tra singoli collegamenti e pulsanti riuniti in elenchi e in gruppi. Tale distanza è stabilita in 0,5 em, che indica la metà della grandezza del carattere impostato per i collegamenti e le etichette dei pulsanti da distanziare.

Reputiamo ottima la scelta di definire una misura di soglia, solo che il requisito 21 non spiega in che modo debba essere definita la distanza di 0,5 em tra elementi adiacenti o consecutivi, il che può portare a incertezze e differenze in sede di applicazione.

Prendiamo i due elenchi in Figura 21.2. In quello marcato con la lettera A, abbiamo definito l’interlinea, cioè la distanza tra le basi di due righe consecutive, tramite la proprietà CSS line-height: 1.5em. Il valore 1.5 equivale alla somma di 1 em, che è lo spazio occupato verticalmente dai caratteri di testo, e 0.5 em, che è la distanza di separazione richiesta dal requisito 21.

Nell’elenco marcato con la lettera B, invece, abbiamo eliminato la definizione della proprietà line-height, sostituendola con la coppia proprietà/valore margin-bottom: 0.5em. Questa proprietà definisce lo spazio verticale posto sotto ciascun elemento LI della lista B.

Entrambi i sistemi dovrebbero portare al medesimo risultato, quello cioè di stabilire una spaziatura di 0,5 em tra due punti elenco consecutivi. Tuttavia, come si può vedere dal confronto tra gli elenchi A e B in Figura 21.2, l’uso di margin-bottom, o anche di padding-bottom, crea uno spazio verticale leggermente maggiore rispetto a quello ottenuto con l’uso di line-height (questo perché il valore predefinito di line-height è in genere un po’ superiore a 1 em).

Insomma, anche per questo requisito sarebbe stato d’aiuto per gli sviluppatori poter disporre di chiarimenti forniti dal legislatore sulle modalità di applicazione. Ci auguriamo vivamente che future revisioni del decreto 8 luglio 2005 provvederanno a fornire, insieme con le regole, anche i necessari esempi applicativi.

Inizio pagina

Requisito 22. Creare pagine alternative accessibili per le pagine che non possono essere rese direttamente accessibili

Per le pagine di siti esistenti che non possano rispettare i suelencati requisiti (pagine non accessibili), in sede di prima applicazione, fornire il collegamento a una pagina conforme a tali requisiti, recante informazioni e funzionalità equivalenti a quelle della pagina non accessibile e aggiornata con la stessa frequenza, evitando la creazione di pagine di solo testo; il collegamento alla pagina conforme deve essere proposto in modo evidente all’inizio della pagina non accessibile.

Il requisito 22, ultimo della serie, si richiama al punto di controllo 11.4 delle WCAG 1.0 e allo standard 1194.22 (k) della Section 508 statunitense.

La legge americana richiede però di fornire, come equivalente per le pagine web che non possono essere rese direttamente accessibili, una pagina di solo testo, che è proprio ciò che il requisito della legge italiana proibisce (... evitando la creazione di pagine di solo testo). Riportiamo, per ragioni di confronto, il testo tradotto in italiano del paragrafo 1194.22 richiamato dal requisito 22:

(k) Sarà fornita una pagina di solo-testo, con informazioni o funzionalità equivalenti, per rendere un sito web conforme alle prescrizioni di questi standard, quando la conformità non può essere ottenuta in altra maniera. Il contenuto della pagina di solo-testo sarà aggiornato ogni volta che la pagina primaria cambia.

È interessante anche il confronto con il punto di controllo 11.4 delle WAG 1.0, con il quale la parentela del requisito 22 è più evidente:

Se, nonostante ogni sforzo, non è possibile creare una pagina accessibile, fornire un collegamento a una pagina alternativa che usi le tecnologie del W3C, sia accessibile, abbia informazioni (o funzionalità) equivalenti e sia aggiornata altrettanto spesso della pagina (originale) inaccessibile.

Per una serie di considerazioni sulla differenza tra pagine, versioni e siti alternativi, si veda il commento al punto di controllo 11.4, alla fine del Capitolo 16.

Quel che è importante notare, a proposito del requisito 22, è che la possibilità di creare una pagina alternativa accessibile per pagine web inaccessibili viene considerata valida solo per siti esistenti e in sede di prima applicazione. Ciò vuol dire che in un sito di nuova creazione non sarà possibile realizzare pagine alternative accessibili a fianco di pagine non accessibili: ogni singola pagina di un nuovo sito web conforme alle legge 4/2004 deve essere costruita, dunque, in modo da essere direttamente accessibile, tramite l’applicazione dei 21 requisiti precedenti.

Inizio pagina

Considerazioni finali sulla legge 4/2004 e sui 22 requisiti tecnici

Il 16 aprile 2007 il Ministro per le Riforme e l’Innovazione nella Pubblica Amministrazione, Luigi Nicolais, ha varato un decreto intitolato Riorganizzazione del Dipartimento per l’innovazione e le tecnologie , leggibile sul sito del Dipartimento.

Tra le varie redistribuzioni di incarichi definite dal decreto, interessa per chi si occupa di accessibilità quella relativa all’Ufficio III, preposto all’ordinamento giuridico della società dell’informazione. Tra i suoi compiti, è prevista, infatti, un’attività di monitoraggio e aggiornamento sulla normativa per l’accessibilità:

Servizio I – Attività normativa. Cura la predisposizione e l’attuazione della normativa primaria e secondaria per lo sviluppo della società dell’informazione, con particolare riferimento al Codice dell’amministrazione digitale e alla normativa sull’accessibilità;  in tali ambiti cura e verifica l’attuazione della suddetta normativa ed effettua il monitoraggio delle attività da essa prevista presso le amministrazioni; provvede, altresì, a predisporre le relazioni annuali previste dalla normativa e svolge le funzioni di segreteria della Conferenza permanente per l’innovazione tecnologica nelle amministrazioni dello Stato; in raccordo con l’Ufficio legislativo del Ministro e con il Cnipa predispone la normativa tecnica […].

L’attività descritta nel brano citato s’inscrive in una più vasta serie di attività del Dipartimento per l’Innovazione e le Tecnologie, legate a una politica di riduzione del cosiddetto digital divide (cioè la separazione tra chi possiede e usa le nuove tecnologie e chi, invece, ne è escluso). Una delle ramificazioni di questa politica è il Progetto Accessibilità , che prevede il raggiungimento dei seguenti obiettivi:

• monitoraggio e controllo del rispetto, da parte delle amministrazioni statali, delle disposizioni della legge;
• verifica del mantenimento dei requisiti di accessibilità dei siti e dei servizi forniti;
• vigilanza sui contratti stipulati dalla pubblica amministrazione centrale e locale perché rispettino la normativa in materia di accessibilità;
• attività promozionali e di incentivazione anche congiuntamente con altre amministrazioni;
• autorizzazione all’uso del logo che attesta l’accessibilità del sito o del materiale informatico prodotto, nei confronti di soggetti privati;
• l’aggiornamento annuale delle regole tecniche, contenute nel DM 8 luglio 2005, di competenza del Ministro;
• predisposizione della relazione annuale del Ministro al Parlamento.

Intanto, il 4 e il 23 aprile 2007 si è riunita presso la sede del CNIPA la Commissione Interministeriale Permanente per l’impiego delle Tecnologie ICT per le Categorie Deboli e Svantaggiate, presieduta dal Prof. Ridolfi, con lo scopo di esaminare una serie di proposte per migliorare il livello di applicazione della legge sull’accessibilità.

Dai verbali delle due riunioni, consultabili online (verbale 4 aprile 2007 e verbale 23 aprile 2007 ), emergono alcuni temi di discussione che sembrano preludere a un tentativo di portare la legge 4/2004 verso un più accettabile livello di applicazione da parte dei soggetti obbligati:

Il Presidente e i membri della commissione discutono una serie di proposte per una maggiore cogenza della legge sull’accessibilità. A tale riguardo vengono suggerite le seguenti proposte:

• lettera di richiamo ad amministrazione inadempiente;
• pubblicazione di una Black – List;
• pubblicazione di una White - List;
• blocco dei pareri del Cnipa a enti e/o amministrazioni inadempienti;
• valutazione da parte degli uffici legislativi e coinvolgimento della Conferenza Stato-Regioni, per gli aspetti delle autonomie locali.

I riferimenti che abbiamo citato sono le informazioni più recenti in nostro possesso, alla data di chiusura del libro, relative all’attività del Governo e degli enti preposti per migliorare l’applicazione della legge sull’accessibilità. Questi documenti testimoniano di una volontà istituzionale di non abbandonare la legge 4/2004 a un destino di più o meno completo oblio, comune a tante altre leggi italiane. Vedremo nei prossimi mesi se le attività previste dal Progetto Accessibilità e gli interventi che la Commissione Interministeriale deciderà sortiranno gli effetti sperati.

Quel che è certo è che le regole di riferimento per implementare l’accessibilità e verificare il livello raggiunto nei siti web della Pubblica Amministrazione sono e restano, almeno fino a che non verrà promulgato un decreto di aggiornamento, i ventidue requisiti tecnici che abbiamo esaminato nelle pagine precedenti.

Un elemento positivo di tali requisiti è, a nostro parere, la loro diretta derivazione dallo standard internazionale per l’accessibilità dei contenuti web, cioè le WCAG 1.0. Infatti, in mancanza di una ricerca scientifica autonomamente condotta nel nostro Paese, volta a determinare una nuova griglia di regole tecniche per l’accessibilità, alternativa rispetto agli standard prodotti dal W3C, la cosa migliore era restare ancorati a quelle 14 linee guida e a quei 65 punti di controllo che, dal 1999, sono l’unico vero riferimento, a livello mondiale, per lo sviluppo di contenuti web accessibili.

Del resto, gli Stati Uniti avevano fatto la stessa cosa già nel lontano 2001, estrapolando dalle WCAG 1.0 un sottoinsieme di regole, che, con qualche modifica e qualche taglio rispetto al testo del documento W3C, è poi confluito nelle prescrizioni che costituiscono il paragrafo 1194.22 della Section 508, intitolato Web-based Intranet and Internet Information and Applications.

La legge italiana, inoltre, non solo si richiama direttamente agli standard internazionali e, in particolare alle WCAG, ma, tramite il comma 2 dell’articolo 12, stabilisce anche il periodico aggiornamento del decreto contenente i requisiti tecnici, in modo da mantenersi al passo con l’evoluzione degli standard in materia di accessibilità:

Il decreto di cui all’articolo 11 è periodicamente aggiornato (...) per il tempestivo recepimento delle modifiche delle normative di cui al comma 1 e delle innovazioni tecnologiche nel frattempo intervenute.

Inizio pagina

Confronto tra il paragrafo 1194.22 della Section 508 e l’Allegato A del decreto di attuazione 8 luglio 2005

Tutto bene, allora? O c’è qualcosa che non va? A parte le questioni che riguardano gli aspetti più propriamente giuridici della legge (sanzioni, attività di controllo ecc.), sulle quali abbiamo riferito velocemente a inizio capitolo, esistono a nostro parere alcuni problemi legati specificamente all’aspetto tecnico, cioè ai ventidue requisiti.

Chi ha letto con attenzione l’enunciato di quei requisiti e i nostri commenti, avrà notato che in più di un caso il modo in cui gli enunciati sono formulati lascia adito a dubbi e a differenti interpretazioni. È strano, in effetti, che, nonostante il lungo lavoro di consultazione e confronto tra esperti tecnici, associazioni di disabili, produttori di software, che ha preceduto la pubblicazione del decreto contenente i requisiti, il testo finale presenti ambiguità, formule troppo astratte e persino refusi, come se nessuno si fosse preso la briga, una volta trovato l’accordo sui concetti, di mettersi a lavorare sulla forma in cui erano stati espressi, nel tentativo di eliminare imprecisioni e oscurità. Sia detto, questo, senza alcuna intenzione offensiva verso le persone che hanno partecipato alla definizione degli attuali requisiti: sappiamo che hanno lavorato con abnegazione, facendo del loro meglio e sacrificando gratis il proprio tempo per partecipare alle riunioni dei gruppi di lavoro.

Comunque sia, il confronto tra il paragrafo 1194.22 della Section 508 americana e l’allegato A del decreto 8 luglio 2005, che contiene i ventidue requisiti tecnici per la legge italiana, è purtroppo impietoso: le sedici linee guida della legge americana sono espresse con un linguaggio preciso, sintetico, inequivocabile, mentre molti dei requisiti del nostro decreto sono avvolti in formule fumose, se non in vere e proprie imprecisioni. Potremmo fare numerosi confronti per avvalorare la tesi, ma crediamo che basti quanto segue per chiarire il concetto.

Proviamo a leggere in sequenza lo standard 1194.22 (j) della Section 508 e il requisito 5 del decreto italiano, che a quello esplicitamente si richiama:

1194.22 (j). Le pagine devono essere progettate evitando di produrre sfarfallamenti dello schermo che abbiano una frequenza maggiore di 2 Hz e minore di 55 Hz.

Requisito tecnico 5. Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di intermittenza possano provocare disturbi da epilessia fotosensibile o disturbi della concentrazione, ovvero possano causare il malfunzionamento delle tecnologie assistive utilizzate; qualora esigenze informative richiedano comunque il loro utilizzo, avvertire l’utente del possibile rischio prima di presentarli e predisporre metodi che consentano di evitare tali elementi.

Tra i due enunciati passa una differenza enorme, che è forse la miglior fotografia della differenza che esiste tra la mentalità americana, pragmatica e non amante dei fronzoli, e la mentalità italiana che, anche quando è mossa, come in questo caso, dalle migliori intenzioni, non riesce a evitare formule prolisse, astratte, burocratiche e, soprattutto, ambigue.

Indipendentemente dal suo valore reale per l’accessibilità, il pregio essenziale dell’enunciato della Section 508 è che è assolutamente preciso, inequivocabile, come si richiede a una prescrizione di legge. Può pertanto essere applicato e, soprattutto, verificato senza ambiguità. È solo una questione di tecnica, non di comprensione del significato: se una pagina contiene un oggetto che sfarfalla con una frequenza, poniamo, di 10 Hz, sapremo con certezza che ha violato il requisito (j) della legge statunitense sull’accessibilità. Al legislatore americano non interessava scrivere una regola che descrivesse il problema di accessibilità da evitare (le crisi da epilessia fotosensibile); gli interessava, invece, dare una prescrizione chiara, che potesse essere capita e applicata da chi, per lavoro, fa siti web e non il medico.

Il requisito 5 della legge italiana, al contrario, pur citando come riferimento l’enunciato di 1194.22 (j), preferisce descrivere minuziosamente i problemi di accessibilità che vuole evitare, senza però fornire alcuna regola pratica che permetta a grafici e sviluppatori di produrre contenuti web che abbiano una frequenza d’intermittenza non pericolosa.

Dice, infatti: Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di intermittenza possano provocare disturbi da epilessia fotosensibile o disturbi della concentrazione.... Sì, ma quali sono queste frequenze? Il legislatore americano lo dice esplicitamente, magari allargando per eccesso la gamma di frequenze proibite, mentre il legislatore italiano preferisce tacere e lasciare tutto alla discrezionalità degli sviluppatori.

Ma, quel che è peggio, il requisito italiano contiene allo stesso tempo la regola e la sua negazione. Prima chiede di evitare oggetti e scritte lampeggianti o in movimento. Subito dopo concede di usarle qualora esigenze informative richiedano comunque il loro utilizzo. Quali esigenze informative? Il requisito non lo precisa. Ancora una volta è tutto rimesso alla discrezionalità dello sviluppatore.

Fatto sta che, così come è espresso, il requisito 5 può essere superato anche se sono presenti sulla pagina oggetti sfarfallanti, qualsiasi sia la loro frequenza. L’unico errore che può far fallire la sua applicazione è la presenza di oggetti sfarfallanti non preceduti da alcun avviso e inseriti in un contesto in cui la loro visione non può essere evitata. Ma allora perché non limitarsi a un enunciato che esprima solo ed esclusivamente la condizione che si ritiene sufficiente per il superamento del requisito? Per esempio: Se una pagina web contiene oggetti sfarfallanti, avvertire preventivamente l’utente che la loro visione può causare attacchi epilettici e predisporre metodi che consentano di evitarli.

Un altro caso analogo a quello del requisito 5 – in cui regola e negazione della regola coesistono – è quello del requisito 13, che spiega come debbano essere usate le tabelle d’impaginazione, nonostante il requisito 1 avesse già stabilito che gli elementi e gli attributi dei linguaggi di marcatura vanno usati secondo le specifiche (il che implica, a nostro avviso, la conseguenza che le tabelle possano essere usate in HTML solo per incasellare dati tabellari e non a scopo d’impaginazione).

Senza dilungarci ulteriormente, crediamo che sia ormai chiaro al lettore quello che è, secondo noi, il principale problema applicativo che affligge non pochi dei ventidue requisiti tecnici della legge italiana: l’ambiguità, la mancanza di regole applicative semplici, chiare e univoche.

A peggiorare la situazione, va citato il fatto che questi requisiti sono presentati, come si suol dire, “nudi e crudi”. Non c’è neppure l’ombra, in tutto il decreto 8 luglio 2005, di un esempio che mostri praticamente “come si fa”. Ancora una volta, il confronto con il paragrafo 1194.22 della Section 508 si rivela impietoso per noi italiani: l’enunciato di ognuno dei sedici requisiti di accessibilità della legge americana è accompagnato, infatti, da chiarimenti ed esempi applicativi, che semplificano di molto il compito degli sviluppatori.

Insomma, una legge è una legge: se non dà prescrizioni tecniche chiare e applicabili, anche in presenza del miglior apparato di sanzioni e controlli, non può dare gli effetti sperati. Per questo ci auguriamo che il legislatore, che già si è mostrato sensibile e ben disposto verso il problema di accesso al Web degli utenti con disabilità, rendendosi conto delle carenze dell’attuale decreto sui requisiti tecnici, decida al più presto di metterne in cantiere una nuova versione.

Ci permettiamo infine, immodestamente, di suggerire tre caratteristiche che ci piacerebbe trovare in un futuro aggiornamento di questo decreto:

1. l’adozione delle WCAG 2.0 come fonte d’ispirazione, al posto delle ormai anziane WCAG 1.0 (anche in considerazione del fatto che il meccanismo dei criteri di successo, su cui si basano le WCAG 2.0, è studiato appositamente per rendere più semplice e meno ambigua l’implementazione e la verifica delle caratteristiche di accessibilità);
2. la presenza di una nutrita schiera di esempi applicativi (quanto meno uno per ciascun requisito);
3. l’adozione di uno stile di scrittura “americano” per gli enunciati dei requisiti: se si decide di discostarsi dal dettato delle WCAG, si scelga almeno una fraseologia semplice e diretta, inequivocabile. Invece di ricorrere a formule astruse come ... usare gli elementi ... e gli attributi previsti dalla DTD adottata per descrivere i contenuti e identificare le intestazioni di righe e colonne, non sarebbe infinitamente più semplice formulare in modo aperto e diretto le richieste a cui gli enunciati alludono? Per esempio: In tabelle HTML o XHTML, marcare le celle d’intestazione con TH e usare l’attributo summary per descrivere il contenuto.

Inizio pagina