A quattro anni dalla pubblicazione del DM 8 luglio 2005 è il momento di tirare le somme.
Quasi due anni fa pubblicai alcuni articoli in cui analizzavo criticamente la metodologia di verifica tecnica alla quale deve attenersi chiunque valuti un sito per la conformità alla legge 4/2004. In questo articolo riprendo, correggo e amplio quelle critiche.
Premessa
I miei commenti e suggerimenti si riferiscono esclusivamente ai paragrafi 1 e 2 dell’articolo 5 del Decreto Ministeriale 8 luglio 2005 e alla metodologia di verifica tecnica enunciata al paragrafo 2 dell’Allegato A del medesimo decreto, e sono formulati sulla base della mia esperienza degli ultimi anni come tecnico esecutore di verifiche basate sulla suddetta metodologia.
1 – La validazione sintattica
L’articolo 5 del DM 8 luglio 2005 dichiara:
2. Nella verifica tecnica l’esperto tecnico, applicando la metodologia di cui all’allegato A, paragrafo 2: a) svolge le attività previste alla lettera a) del medesimo paragrafo 2 su tutte le pagine del sito;
La lettera a) del paragrafo 2 dell’Allegato A afferma:
a) riscontro, con sistemi di validazione automatica, della rispondenza alla sua definizione formale del linguaggio a marcatori utilizzato;
In sostanza si richiede la validazione di tutte le pagine del sito rispetto alla DTD dichiarata nei documenti. Questo comporta l’uso di un parser SGML, come per esempio il W3C Markup Validation Service o software di validazione automatica come CSE HTML Validator.
È davvero necessario validare tutte le pagine del sito?
In base alla mia esperienza, ritengo privo di senso richiedere l’analisi sintattica dell’intero sito. Questo perché:
- I siti sono generalmente gestiti da CMS (Content Management Systems) in base a un numero limitato di template e le pagine generate sono spesso identiche. Gli errori sintattici nella struttura delle pagine sono quindi ripetitivi.
- Gli errori sintattici redazionali (che riguardano cioè il contenuto e non la struttura delle pagine) sono anch’essi generalmente ripetitivi.
Alla luce di ciò l’analisi potrebbe limitarsi alle prime 1.000 pagine (o a un numero che si decida essere statisticamente rilevante). L’analisi inizierebbe dall’Home Page seguendo tutti i collegamenti presenti (e così per le pagine successive nella gerarchia) fino al raggiungimento del limite numerico scelto.
Nel caso di siti nei quali esistono sezioni/applicazioni importanti situate in profondità, si dovrebbe procedere all’analisi sintattica anche di queste ultime. In queste situazioni è essenziale la collaborazione con il gruppo di lavoro tecnico della PA, o dell’azienda, che provvederà ad indicare al valutatore la presenza di queste sezioni “profonde” prima dell’esecuzione della verifica tecnica.
Questo cambio di approccio è necessario anche considerato il fatto che attualmente il software più potente per l’esecuzione di analisi sintattiche automatiche di interi siti (CSE HTML Validator) ha un limite nel numero delle pagine analizzabili. Questo limite può essere superato agendo direttamente sul registro di sistema di Windows, ma l’incremento del valore massimo predefinito può provocare inconvenienti come il crash dell’applicazione o il blocco dell’intero sistema. Di fatto, quindi, nessun valutatore ha potuto eseguire test sintattici su tutte le pagine dei siti analizzati, salvo nei rari casi di micro-siti.
2 – Il campione statistico
L’articolo 5 della legge 4/2004 dichiara che l’esperto tecnico:
b) svolge le attività previste alle lettere b), c) e d) del medesimo paragrafo 2 […] nonché su un campione statistico di pagine, non rientranti in quelle esaminate precedentemente, pari al 5% delle stesse;
Nella mia esperienza la ricerca di un 5% di pagine non rientranti in quelle esaminate precedentemente (che fossero, cioè, differenti nel design da quelle già analizzate) è stata spesso difficoltosa se non in alcuni casi impossibile. Questo per i motivi già addotti: i siti sono generalmente gestiti da CMS in base a un numero limitato di template e le pagine generate sono spesso identiche. Questa realtà ha reso sostanzialmente inutile la ricerca di tale campione.
Abbandonerei, quindi, completamente il riferimento al campione statistico di pagine. L’analisi dovrebbe essere estesa a nuove pagine a discrezione del valutatore solo nelle situazioni in cui fossero individuati, all’interno del sito in esame, template differenti non compresi nelle pagine precedentemente analizzate. Una pagina template è un modello utilizzato per creare nuove pagine dal design, struttura e stile coerenti. Quindi siamo di fronte a un template differente ogni qual volta cambia in qualche aspetto il design, la struttura o lo stile della pagina.
L’individuazione dei differenti template all’interno del sito dovrebbe scaturire da una collaborazione tra il valutatore e i referenti tecnici delle PA o delle aziende coinvolte. Questi ultimi potrebbero aiutare il valutatore a:
- individuare i differenti template presenti nel sito (anche nel caso della presenza di sezioni “profonde” del sito);
- segnalare le sezioni che necessitano di particolare attenzione.
Insieme a ciò l’analisi delle statistiche di accesso potrebbe orientare nella scelta di particolari sezioni del sito da analizzare (per esempio sezioni visitate spesso dagli utenti ma non rientranti in quelle già analizzate o da analizzare).
È importantissimo stimolare la collaborazione tra valutatore e soggetto valutato, il carattere censorio della valutazione, percepito in maniera negativa, unito alla mancanza di vere sanzioni ha, secondo me, contribuito non poco alla scarsa applicazione della Legge 4/2004. Al contrario di quanto taluni affermano, non sono i requisiti tecnici che hanno causato la scarsa applicazione della Stanca: i requisiti sono coerenti con le raccomandazioni internazionali e anche il peggior critico, se si prenderà la briga di leggerli davvero, scoprirà che applicarli non è così complicato. La verità è che è la totale mancanza di sanzioni che ha favorito la naturale indolenza dei dirigenti della PA.
3 – le pagine e i siti esterni al dominio
L’articolo 5 del DM 8 luglio 2005 dichiara che l’esperto tecnico:
b) svolge le attività previste alle lettere b), c) e d) del medesimo paragrafo 2 sulla home page, su tutte le pagine del sito direttamente raggiungibili dalla home page, […]
La determinazione di quali siano le pagine direttamente raggiungibili dall’Home Page “realmente” soggette all’analisi ha spesso sollevato noiose discussioni nel concreto del lavoro di verifica.
La soluzione adottata (applicando il principio che i collegamenti a siti esterni al dominio in esame devono essere esclusi dalla verifica) è la seguente:
Per definire l’appartenenza a un sito si devono considerare il ccTLD (Country Coded Top Level Domains, per esempio “.it” o “.de”) o il gTLD (Generic Top Level Domain, “.com”, “.net” ecc.) + l’SLD (Second Level Domain, dominio di secondo livello).
Quindi un indirizzo del tipo: http://sezione.miosito.it fa sempre parte del sito http://www.miosito.it/ dato che ccTLD e SLD sono invariati rispetto all’Home page.
Questo con le importanti eccezioni di:
- Domini geografici:
http://www.provincia.genova.it/ è evidentemente diverso da http://www.comune.genova.it/. In questi casi il dominio di terzo livello è significativo per definire l’appartenenza o meno a siti differenti.
- Dominio gov.it: nel caso dei siti di PA centrali alle quali è assegnato il dominio gov.it saranno i domini di primo, secondo e terzo livello a determinare l’appartenenza al sito, per esempio:
http://www.amministrazione.gov.it e http://sezione.amministrazione.gov.it appartengono allo stesso sito.
Lo stesso principio si applica ad altre situazioni, per esempio nel caso di http://www.aeronautica.difesa.it/ sono i domini di primo, secondo e terzo livello a determinare l’appartenenza al sito. Quindi una sezione con indirizzo: http://sezione.aeronautica.difesa.it/ appartiene al sito (analogamente a quanto avviene per i domini gov.it).
In alcuni casi le amministrazioni e le aziende valutate hanno lamentato che sezioni del loro sito, con ccTLD e SLD identici alla Home page, erano gestite da altri gruppi di lavoro e che quindi le avrebbero considerate come pagine non appartenenti al sito. Questo non è accettabile: se il gestore di un sito espone il suo SLD all’utilizzo da parte di terze parti che producono siti inaccessibili se ne deve assumere la responsabilità e, al limite, non concederne più l’utilizzo.
Vale anche il contrario: esistono PA che gestiscono internamente sezioni del loro sito con ccTLD e SLD diversi dalla Home page. La mia opinione è che in questo caso dette sezioni andrebbero inserite nella verifica.
4 – L’analisi dei moduli
L’articolo 5 del DM 8 luglio 2005 dichiara che l’esperto tecnico:
b) svolge le attività previste alle lettere b), c) e d) del medesimo paragrafo 2 […] su tutte le tipologie di pagine che presentano form e di pagine di risposta […]
Sarebbe più corretto dire “su tutte le tipologie di pagine che presentano form e sulle rispettive pagine di risposta”.
L’analisi di tutte le tipologie di pagine che presentano form e delle rispettive pagine di risposta è essenziale per valutare l’accessibilità. Spesso però i moduli sono gestiti in modo tale che risulta complicato analizzare la/le pagina/e di risposta. In questi casi l’unica cosa sensata è limitare l’analisi al modulo.
E’ necessario inoltre che la Pubblica Amministrazione o l’azienda supporti il valutatore nel caso di procedure di compilazione che comportano passi successivi e/o procedure di autenticazione per la compilazione del modulo.
Un aspetto ambiguo nelle indicazioni della metodologia può essere la definizione di “tipologia di pagina che presenta form”. Personalmente nella mia esperienza di lavoro ho considerato “differenti” tutti i moduli che presentavano pulsanti, campi di input ecc. diversi per tipo (input, select, textarea ecc.), o numero.
5 – Semantica
La lettera b) del paragrafo 2 dell’Allegato A del DM 8 luglio 2005 afferma:
b) verifica dell’esperto tecnico sul corretto utilizzo semantico degli elementi e degli attributi secondo le specifiche del linguaggio a marcatori impiegato, anche mediante l’uso di strumenti semiautomatici di valutazione allo scopo di evidenziare problemi non riscontrabili dalle verifiche automatiche;
La mia opinione è che questa lettera debba essere mantenuta così com’è. La corretta strutturazione dei contenuti e il rispetto della semantica sono troppo importanti per l’accessibilità. Questo è peraltro coerente con le indicazioni dei criteri di successo 1.3.1 e, in particolare, 4.1.1 delle WCAG 2.0.
6 – Esame della pagina
La lettera c) del paragrafo 2 dell’Allegato A del DM 8 luglio 2005 afferma:
c) esame della pagina con varie versioni di diversi browser grafici in vari sistemi operativi allo scopo di verificare che: […]
È normale che in un decreto non siano indicati esplicitamente i browser e le versioni con i quali bisogna esaminare le pagine, ma per evitare confusione e l’applicazione di una retro-compatibilità spesso priva di senso, sarebbe opportuno specificare e limitare il campo d’azione, per esempio dicendo:
- Le ultime due versioni disponibili dei principali sistemi operativi;
- Le ultime due versioni disponibili dei principali browser grafici.
1) il contenuto informativo e le funzionalità presenti in una pagina siano gli stessi nei vari browser;
Il punto 1) non deve essere modificato.
2) la presentazione della pagina sia simile nei browser che supportano le tecnologie indicate al requisito n. 1 di cui al paragrafo 4 del presente allegato
Anche in questo caso non vedo necessità di modifiche: il termine “simile” consente già sufficienti gradi di libertà al designer.
3) il contenuto informativo e le funzionalità della pagina siano ancora fruibili in caso di disattivazione del caricamento delle immagini;
Anche il punto 3), per ovvi motivi, non deve essere modificato.
4) i contenuti informativi di eventuali file audio siano fruibili anche in forma testuale;
Questo punto, come molte altre indicazioni presenti nella metodologia, potrebbe non essere più necessario perché naturalmente integrato nell’adeguamento dei 22 requisiti alle nuove WCAG 2.0. È comunque un principio di accessibilità imprescindibile.
5) i contenuti della pagina siano fruibili in caso di utilizzo delle funzioni previste dai browser per definire la grandezza dei caratteri;
Valgono le stesse considerazioni fatte per il punto 4).
6) la pagina sia navigabile con il solo uso della tastiera e l’impiego di una normale abilità;
Valgono le stesse considerazioni fatte per il punto 4).
7) i contenuti e le funzionalità della pagina siano ancora fruibili, anche in modalità diverse, in caso di disattivazione di fogli di stile, script e applet ed altri oggetti di programmazione;
Valgono le stesse considerazioni fatte per il punto 4). Il punto 7) crea problemi per una serie di applicazioni “2.0″ non accessibili o per framework come SCORM. La mia ben nota opinione è la seguente:
Quando si affronta il discorso sulla legge 4/2004 gli interlocutori sono le amministrazioni pubbliche italiane e le aziende private che lavorano con esse.
Un’azienda privata può decidere se perseguire o meno, per sé e per i suoi clienti privati, una politica di responsabilità sociale. Nessuno può sindacare questa scelta. Ma per la pubblica amministrazione il discorso cambia. Se concordiamo sul fatto che le amministrazioni pubbliche esistono per curare gli interessi della collettività, in particolare fornendo servizi ai cittadini, e che un disabile è a tutti gli effetti un cittadino come gli altri, allora è semplicemente inaccettabile che un’amministrazione discrimini anche una sola persona utilizzando una tecnologia non accessibile.
8) i contenuti e le funzionalità continuino a essere disponibili con un browser testuale e i medesimi contenuti mantengano il proprio significato d’insieme e la corretta struttura semantica;
Devo dire che considero il punto 8) un po’ esagerato in particolare per ciò che concerne le funzionalità che in alcuni casi non possono essere riprodotte in un contesto puramente testuale. Mentre concordo sulla necessità del mantenimento del significato d’insieme e della corretta struttura semantica.
7 – Contrasto colore
La lettera d) del paragrafo 2 dell’Allegato A del DM 8 luglio 2005 afferma:
d) verifica delle differenze di luminosità e di colore tra il testo e lo sfondo secondo i seguenti algoritmi:
1) differenza di luminosità: calcolo della luminosità dei colori di testo e di sfondo con la formula: ( (Rosso X 299) + (Verde X 587) + (Blu X 114) ) / 1000, in cui Rosso, Verde e Blu sono i valori decimali dei colori; il risultato deve essere non inferiore a 125.
2) differenza di colore: calcolo della differenza di colore con la formula[Max (Rosso1, Rosso2) - Min (Rosso1, Rosso2)] + [Max (Verde1, Verde2) - Min (Verde1, Verde2)] + [Max (Blu1, Blu2) — Min (Blu1, Blu2)], in cui Rosso, Verde e Blu sono i valori decimali dei colori e Max e Min il valore massimo e minimo tra i due presi in considerazione; il risultato deve essere non inferiore a 500;
In questo caso va da se, data l’obsolescenza di questi algoritmi, l’adozione delle indicazioni in merito presenti nelle nuove WCAG. Sarebbe meglio inoltre non pubblicare esplicitamente un algoritmo perché ciò vincola e impedisce l’adeguamento alle novità della ricerca in questo campo. Molto meglio adottare il concetto di “rapporto di contrasto” delle WCAG 2.0 (criteri di successo 1.4.3 e 1.4.6).
8 – Rapporto conclusivo
La lettera e) del paragrafo 2 dell’Allegato A del DM 8 luglio 2005 afferma:
e) redazione di un rapporto nel quale l’esperto tecnico indica la conformità, la non conformità o l’eventuale non applicabilità di ogni singolo requisito della pagina esaminata.
Per siti di grandi dimensioni questo obbliga alla produzione di una quantità immensa di materiale cartaceo sostanzialmente inutile. Personalmente ritengo più utile la produzione di un unico rapporto conclusivo che evidenzi tutte le tipologie di errori riscontrati (insieme ad una spiegazione e magari qualche consiglio) e con l’indicazione della pagina alla quale si riferiscono. Nel caso di errori ricorrenti (cosa molto frequente) sarà sufficiente indicare la prima occorrenza specificando che l’errore è, appunto, ricorrente.
Articoli correlati
