Blog ad Improbabilità Infinita

Mi è capitato di leggere questa notizia su Punto Informatico. Detto in breve: "Il sito istituzionale della Provincia di Milano è stato riconosciuto dal CNIPA (Centro Nazionale per l'Informatica nella Pubblica Amministrazione) come sito accessibile ed ha, quindi, autorizzato la pubblicazione del logo che ne attesta l'accessibilità."

Il logo di cui si parla, personalmente di stile obsoleto, in quanto ricorda elaboratori degli anni '80, ma svecchiato da gioiosi omini con le braccia sulle 10:10, è questo:

Per non parlare del fatto che mi ricorda abbastanza quello di Ubuntu 😀

Senza entrare in dettagli complicati e di poco interesse per i non addetti ai lavori, certifica il fatto che il sito rispetti numerosi parametri che lo rendano conforme agli standard ed, in particolare, accessibile a persone diversamente abili (non vedenti, ipovedenti, daltonici, non udenti, disabili motori, ecc.).

Gran parte di questi parametri non può essere verificata in maniera automatica per svariati motivi, però alcune caratteristiche basilari sono, per loro stessa natura, validabili da strumenti automatizzati: in particolare la struttura sintattica della pagina e, in un secondo momento, i fogli di stile (CSS), che permettono di gestire la parte di presentazione delle informazioni contenute nella pagina stessa.

Per fare un paragone, è possibile controllare in modo automatico se un testo contiene solo vocaboli italiani, mentre è impossibile controllare con certezza, senza l'ausilio umano, se un testo ha una semantica coerente.

Visto che le caratteristiche verificabili in modo automatico sono oggettive, partirò da quelle (quando farò riferimenti a "requisiti" intendo quelli elencati in questa pagina):

• ho iniziato cliccando sul link in fondo all'articolo di Punto Informatico, quindi sono finito in questa pagina:
  • mi colpisce l'immagine nella sezione sinistra, quella con una specie di Wonder Woman :);
  • come faccio sempre con qualsiasi cosa possa essere un link, prima di cliccare, tengo il cursore sopra per vedere nella barra di stato il link e per osservare l'eventuale tooltip associato;
  • leggo il tooltip "portale urp (Questo link si apre in una nuova finestra)" e scoppio a ridere! Chi conosce anche solo l'XHTML 1.0 Strict, senza saper nulla di accessibilità, avrà già capito dove voglio andare a parare: per far aprire un link in una nuova pagina è necessario utilizzare l'attributo "target", violando le specifiche di XHTML 1.0 Strict, ovvero la specifica seguita per la costruzione del sito stesso. E ciò porta a violare il "Requisito 1": "Per tutti i siti di nuova realizzazione, utilizzare almeno la versione 4.01 dell' HTML o la versione 1.0 dell' XHTML, entrambe con DTD (Document Type Definition - Definizione del Tipo di Documento) di tipo Strict.". Inoltre contraddice l'affermazione "Tutte le pagine sono state validate con il Validatore del W3C (Validator W3C).";
  • per curiosità valido effettivamente la pagina e, magia, passa la validazione! Subito mi salta alla mente Javascript, ed infatti tramite Javascript viene aggiunto in un secondo momento l'attributo "target" a quei link per i quali l'attributo "rel" è impostato ad "external". In fase di validazione, naturalmente, non viene applicato Javascript, quindi l'imbroglio va a buon fine;
  • incidentalmente, guardando il resto del codice JS, vedo che anche la ricerca tramite il form di Google causa l'apertura di un'altra finestra;
  • mi potreste dire: "Il requisito è rispettato, la pagina è valida (staticamente) e l'effetto introdotto da quella porzione di codice Javascript è, in definitiva, utile". Per capire la gravità, pensate che mi sarebbe sufficiente creare una pagina che contenga unicamente il codice XHTML minimo necessario ad introdurre uno script Javascript per creare dinamicamente una pagina assolutamente valida staticamente e che contravvenga a qualsiasi regola.

• mi sposto nella pagina "Tasti d'accesso" e la valido. Un errore (il validatore segnala solo la prima occorrenza, ma si ripete per svariati link) proprio sull'attributo "target", che in questa pagina non viene aggiunto dinamicamente ma scritto direttamente nel codice XHTML. Qui non ci sono scuse che possano reggere :);
• vado alla pagina "22 Punti check-list". Stessa situazione del punto precedente, ma in un link differente;
• vado alla pagina dei "Credits" (che magari non dovrebbe chiamarsi così nella versione italiana del sito!) e la valido. Altre soddisfazioni: oltre al solito attributo "target", questa pagina presenta in svariati elementi gli attributi "align" e "border", aboliti nella versione XHTML Strict in quanto non appartengono allo strato di dati, ma di presentazione. Questo è un errore evidente, basilare e non giustificabile;
• ora basta con la validazione sintattica, sono già "contento" :D! Passo a validare il CSS: questo si può fare semplicemente solo sull'"Homepage", supponendo che in un sito istituzionale non facciano la porcata di modificarlo dinamicamente in base alla pagina in cui ci si trova. Nessun errore, ma ben 243 warning. Chi ha un po' di dimestichezza con i CSS saprà che i warning solitamente sono ignorabili, ma a chi ha sentito parlare di accessibilità trilla un campanellino: possono essere indicatori di problemi.

Non essendo, per ora, particolarmente esperto di accessibilità, e richiedendo una valutazione estremamente lunga, sfrutto uno strumento automatico capace di valutare alcune caratteristiche sotanzialmente oggettive. Per semplicità l'ho provato solo sull'homepage ed effettivamente passa i test oggetivi: questo non vuol dire che sia accessibile, ma è un buon inizio :). Per una verifica vera serve l'intervento dell'uomo e la consulenza di disabili, cose che, da quanto dichiarano, hanno fatto per ottenere il bollino.

Proseguo con un elenco di errori ed osservazioni (anche sull'accessiblità, dettate dal mio buon senso più che dalle conoscenze sul campo) sul sito stesso:

• nella pagina dell'"Accessibilità": un po' di rispetto per l'inventore del web! Si chiama Tim Berners-Lee e non Tim Barnes Lee; da cambiare il pusher di citazioni? :D;
• nella pagina dei "Tasti d'accesso": prima vengono spiegate delle combinazioni che funzionano solo sotto Windows, poi viene spiegato come funzionano sotto Windows e sotto Mac; oltre alla ridondanza di informazioni (spiegare due volte come funzionano sotto Windows, la prima implicitamente, pensando che il mondo sia costituito da Windows-iani) non vedo perché non sia contemplato il sistema operativo Linux.
  Inoltre, negli esempi, viene indicato di premere Invio dopo la sequenza, cosa assolutamente inutile.
  Per finire, non esiste il tasto Crlt, ma il tasto Ctrl.
  Non sarebbe molto più chiaro e conciso definire prima le scorciatoie e poi indicare come utilizzarle in ciascun sistema operativo?
• la sezione che contiene i link per modificare la dimensione dei caratteri ed il contrasto tra testo e sfondo è presente solo nell'homepage e sparisce una volta che ci si muove in una qualsiasi altra pagina; immaginatevi di aver navigato un po' il sito, aver raggiunto dopo lunghe fatiche una pagina a lungo agognata ed avere la necessità di modificare qualche parametro: facile, grrr, dovete tornare all'homepage e poi ricercare la pagina precedente!!!
• i tre link che permettono di modificare la dimensione del testo hanno come contenuto testuale "A", che verrà letto da uno screen-reader ovviamente "A" in tutti e tre i casi, quindi un ipovedente dovrebbe andare ad intuizione/tentativi per capire cosa fa ciascuno di essi;
• la parola "Ambiente" per definire il "Contrasto" tra testo e colori è alquanto curiosa (mi ricorda più un suono che un qualcosa di visivo), così come sarebbe meglio sostituire "default" con parole più comuni ad un utente non informatico come "standard" o "normale";
• quando sparisce la sezione descritta precedentemente, appare al suo posto un'altra sezione che indica il percorso di navigazione, fondamentalmente una sorta di "Voi Siete Qui". Bene, utile, ma curiosamente funziona con un buon campione di pagine testate, tranne che con quella dell'"Accessibilità"! 🙂
• guardate in alto a destra: giustamente c'è un link che permette di visitare il sito in lingua inglese. È naturale pensare che, una volta cliccato, faccia sì che tutti i testi nella pagina vengano sostituiti con la corrispondente traduzione inglese. Naaa, sarebbe troppo scontato! Innanzitutto, se lo cliccate, la zona dei link in alto a destra sparisce magicamente, spaesando l'utente che si aspetterebbe di poter ritornare alla versione italiana. Cosa molto peggiore, si finisce in una pagina che non c'entra assolutamente nulla con l'homepage sulla quale ci si trovava e nella quale è tradotta solo una minima parte. Per completare il casino (per usare un tecnicismo), la navigazione delle pagine in inglese si sposta dal menu a sinistra (che rimane in italiano e porta a pagine in italiano) al menu a destra, che permette di raggiungere un numero estremamente scarno di pagine, cioè una sola. Credo che un non vedente, in particolare, troverebbe tutto ciò alquanto fastidioso;
• l'homepage presenta una caterva di link; chi utilizza uno screen-reader se ne deve sorbire davvero troppi prima di poter raggiungere quello che cerca. Se levassero, tanto per dire, il link "Lo Stemma e il Gonfalone" e lo inserissero nella pagina "La Storia della Provincia" ed accomunassero altri link in categorie più generali sarebbe tutto meno pesante da leggere;
• per finire, alcuni tasti di accesso rapido non funzionano con Firefox 2.0.0.3pre sotto Mac.

Credo di aver detto tutto ciò che mi è saltato all'occhio per ora, a voi la parola se scoprite altre cose succose 🙂
Se qualcuno si vuol dilettare gli propongo degli spunti da cui partire: accessibilità di form e di tabelle.