Perchè fanno così paura i requisiti per i siti accessibili? Forse perchè sono stati scritti sotto forma di Legge in modo incomprensibile? Non ve ne do torto, ma se li guardiamo approfonditamente, noterete che non ci allontaniamo da quelle buone e sane regole di usabilità che applichiamo tutti i giorno sui nostri siti. Mascheratamente, qua e là, li abbiamo già conosciuti questi requisiti. Forse che ci fanno più paura messi giù per iscritto? Comunque, per cronaca ora sono 12 e non più 22, e molti sono stati accorpati.

Affrontiamoli un attimo. Avevamo già iniziato a parlarne nella nostra sezione sull’accessibilità, ma evidentemente dobbiamo riassumere per rendervi la cosa più piacevole

Molto brevemente: cos’è l’accessibilità e come affrontarla?

1. Usiamo l’Xhtml 1 strict e validiamolo: metà del lavoro è già fatto. Pertanto scordiamoci frame, target=_blank e altre cavolate
2. Disattivate i css e le immagini del sito: al posto delle immagini compare un testo alternativo? E’ sufficiente a spiegare cosa rappresenta? Il sito vi sembra semanticamente corretto? (vedi header, paragrafi, liste,…)
3. Torniamo alla visualizzazione normale e fate questo test: vi risultano leggibili tutte le parti del sito o c’è qualcosa che sfugge?
   I link si distinguono bene? Seppure fosse, cercate sempre di usare la sottolineatura, purchè gli stessi non siano presenti in menu che chiaramente li identificano come tali.
4. Controllate allora il rapporto di contrasto fra colore di sfondo e testo, in rapporto anche alla grandezza dello stesso, e valutate se è leggibile e corrispondente alle linee guida, eventualmente riadattando i colori.
5. Direi che non c’è bisogno di aggiungere molto sulle gif animate no?

Il resto direi che più che linee guida sull’accessibilità sono anche linee guida di buon senso.
Ad esempio:

1. rendere accessibile il sito anche solo da tastiera, senza dover necessariamente usare il mouse, è una buona pratica e basta poco.
2. inserire un link nascosto, a inizio pagina, che rimandi con un’àncora al div che contiene il testo da leggere è un’altra buona pratica che risparmia tempo ai non vedenti permettendo di saltarsi la lettura del menu ogni volta che si ricarica una pagina nuova, saltando direttamente al “dunque”
3. fare in modo che con css e javascript disabilitati i contenuti (e i menu soprattutto) siano sempre fruibili, è un’altra buona pratica.

Sono sicura che dando una lettura veloce, appuntandosi le cose più “strane” a cui magari non si era mai pensato prima, sarà un modo sufficiente per approfondirle e portarle facilmente nel buon uso comune, tanto più se vengono usate per legge, come per i siti della pubblica amministrazione.
Poi potete usare il CMS che più vi aggrada, purchè rispetti tali requisiti. A mio parere quello che si presta maggiormente, anche per la gestione da parte amministrativa, inutile dirlo, è WordPress, anche grazie a nuovi plugin che ne implementano le funzionalità nello specifico, come “PA facile“.
___________________
Strumenti citati in questo articolo:

1. Sezione sull’accessibilità di Italianwebdesign
2. “Cos’è l’accessibilità dei siti web?” . Italianwebdesign
3. Greybit test: visualizza il tuo sito in biaco e nero
4. Juicy Studio test: rapporto di contrasto fra colore di sfondo e testo
5. Linee guida sull’accessibilità – Sito del Governo Italiano sull’innovazione e PA

Chi di voi non ha ancora fatto un sito per la pubblica amministrazione? Troppe mani alzate, non va bene

Se uno dei freni a fare un sito ad hoc per la PA è stato il problema di dover gestire Albi pretori, Organigrammi, gare, concorsi, delibere, ordinanze, etc non avete più scuse. Ora c’è “PA facile“, un plugin WordPress creato dalla toSend.it volto proprio a gestire tramite custom post types preimpostati tutte queste opzioni obbligatorie e sempre presenti per un sito del genere.

Se poi a frenarvi sono stati i requisiti e le linee guida sull’accessibilità ne parleremo approfonditamente a breve per sollevarvi da qualsiasi dubbio o timore e per approfondire come WordPress possa essere in questo caso uno strumento adeguato e valido (in tutti i sensi).

Enunciato: 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.

La questione mi sembra molto semplice ed evidente: un testo di un colore su sfondo di colore non adeguatamente contrastante risulta non fruibile, pertanto non accessibile. E non è sufficiente valutare “a occhio” che il testo sia leggibile, poichè le varianti di problematiche visive come sapete sono diverse e svariate. L’unico modo certo che abbiamo è di valutare il colore tramite uno strumento del genere:

• Juicy Studio: Luminosity colour contrast ratio analyiser
• Colour contrast analyser (Windows)

Inutile sottolineare che un’immagine usata come testo non è fruibile a meno che non sia usata con l’alternative text relativo. Ora che abbiamo tanti strumenti per usare diversi tipi di font in una pagina html non sono più necessarie le immagini (banner e grafica a parte).

• In altre parole: ok, la gif animata del cagnolino è bellissimissima e carinissima, ma sarà il caso di non inserirla in un testo da leggere? Evitiamo pertanto anche il text-decoration: blink. Oltretutto fa così anni 90, non credete?
• L’enunciato si riferisce fondamentalmente a gif animate con frequenze di lampeggio comprese tra 2 Hz e 55 Hz, ma in realtà rientrano fra questi anche i banner pubblicitari che continuano a loop infinito. A me càpita quando sto leggendo qualche articolo sui principali quotidiani, ed è fastidiosissimo. Mi rendo conto però che anche su Iwd ce ne sono due che possono recar fastidio, e sarà mia premura farlo presente agli sponsor. Evitiamo pertanto anche testi tipo aeroporto con il marquee (a dir la verità neanche negli aeroporti si usano più, vi siete chiesti perchè?)
• Inoltre le transizioni flash o javascript devono essere evitate. Lo so, sono figosissime, ma se il nostro sito è per una PA non possiamo, si rende necessaria una pulizia: con l’epilessia non si scherza.

I primi due punti a mio parere possono essere indice di una buona usabilità anche su siti non destinati alle PA, poichè il movimento è, a livello cognitivo, comunque un elemento di disturbo.

L’essere umano ha fra i suoi istinti atavici, quello della sensazione del pericolo, e un movimento ai lati del campo visivo è nettamente un segno di pericolo. Immaginate una gazzella nella savana che con la coda dell’occhio percepisce un movimento fra l’erba alta: pericolo!! leone!!

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

Forse non tutti lo sanno, ma ben una persona su 12 ha problemi di vista di vario genere, pertanto nella creazione del sito non dobbiamo far sì che funzionalità importanti siano affidate al colore.

Un esempio semplicissimo: in molti usano un colore particolare per evidenziare i link all’interno di una porzione di testo: niente di più sbagliato. O meglio, va bene usare il colore, ma dobbiamo necessariamente associarvi anche l’aspetto fondamentale che ci permette di riconoscere un link: la sottolineatura. Questo per quanto riguarda i link presenti in una porzione di testo, mentre ciò non si rende obbligatorio nel caso vi sia un menu di navigazione che sia evidentemente un insieme di link navigabili.

Es:

In questo menu, già graficamente “decorato” con una sottolineatura che separa le voci, sarebbe ridondante oltre che graficamente disturbante inserire un’ulteriore sottolineatura ai link, poichè già da soli vengono riconosciuti dall’utente come un menu navigabile.

Guardate invece questo secondo esempio.

Mi spiace prenderlo in prestito da un sito che seguo spesso, ma credo ne siano già a conoscenza. Il link come vedete è evidenziato puramente da un colore diverso rispetto al testo. Chi frequenta il sito e comunque non ha problemi, dopo qualche tentativo iniziale, a riconoscere i links, ma chi frequenta il sito per la prima volta e soprattutto ha problemi cognitivi con i colori, ecco cosa vedrà:

Ed ecco che la percezione del link scompare. Provare ad evidenziare il link con il grassetto non risolve il problema, perchè crea confusione proprio con la pura evidenziazione del testo “importante”, cosa che di solito facciamo quando usiamo il grassetto. Non si distinguerebbe comunque il link dal resto poichè il grassetto non è la proprietà principale che permette di associare del testo ad un link.

La stessa cosa vale per quando vogliamo evidenziare una voce selezionata del menu: provate a farne una schermata in bianco e nero e notate se l’evidenziazione funziona comunque.

Per aiutarvi a verificare questo punto c’è un sito che fa al caso nostro: Graybit, che ci permette di valutare, di un sito già pubblicato, come si vedrebbe in scala di grigio. E’ molto utile anche per tutte quelle parti di testo o grafica per le quali non abbiamo usato un adeguato contrasto e che risulterebbero illeggibili per chi ha problemi di cognizione del colore. Ma di questo parleremo in un altro punto dei nostri requisiti.

3 anni di duro lavoro ed un progetto comune: un cms open source interamente accessibile. Zenukers è un progetto tutto italiano, di cui dobbiamo solo andar fieri.

E’ in versione alfa, per cui tutti i consigli per eventualmente migliorarlo sono ben accetti. Ed ora si apre la gara a chi lo testerà per primo per i suoi progetti in linguaggio asp. Sarai fra questi? Io vado subito a scaricarlo.

Per chi non avesse voglia di provarlo ancora, può dargli un’occhiata tramite la demo online e curiosare fra la documentazione online per capire com’è strutturato.

Requisito 3

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.

Riferimenti WCAG 1.0: 1.1, 6.2

Ciò significa che dobbiamo usare sempre il famoso “alt” delle immagini, cosa che ci viene peraltro già segnalata in sede di validazione del codice. Ma come comportarci in linea generale per definire il testo alternativo di un’immagine? Infilandoci anche un pochino di SEO, facciamo in modo che il testo alternativo abbia un senso e renda tutti felici.

Ad esempio, le immagini che uso nei post di italianwebdesign hanno puramente scopo “decorativo”, solo raramente “spiegano” effettivamente ciò che già è rappresentato sottoforma di testo. Pertanto riportare semplicemente ciò che viene evidenziato o nuovamente il testo dell’articolo non fa male a nessuno e aiuta un po’ la Seo.

Nel caso in cui invece le immagini rappresentino, ad esempio, un diagramma di flusso o un grafico, si rende necessaria una descrizione più approfondita, che aiuti i non vedenti ad usufruirne. Forse non molti lo sanno, ma ci viene incontro un attributo del tag <img che si chiama longdesc che richiama una pagina html che contiene la descrizione estesa del contenuto dell’immagine.
Es: <img src="images/grafico.jpg" alt="diagramma" longdesc="diagramma.html" />

Dicasi lo stesso per le mappe, oggetti, pulsanti input, etc (vedi approfondimento).

Roberto Scano

Il codice risulta validato anche con HTML5, perchè non usare questo invece che HTML 4.1 e XHTML 1 come suggerito dai requisiti per l’accessibilità?

Peccato che HTML5 non sarà una specifica ufficiale del consorzio W3C prima del 2014 e quindi secondo il W3C stesso NON vanno utilizzate come riferimento delle specifiche non ancora “standard de facto”.
http://blog.iwa.it/w3c/html5-se-ne-parlera-nel-2014/
Che poi venga spinto per finalità commerciali è un altro discorso, ma normativamente non potrà essere utilizzato in nessuna PA (nemmeno statunitense e/o qualsiasi PA che recepisce le WCAG 2.0) sino al 2014.
HTML 5 NON e sottolineo NON rientra nella legge Stanca in quanto non è specifica stabile del W3C. E – mettetevi il cuore in pace – non rientrerà nemmeno nell’aggiornamento dei requisiti in quanto HTML 5 è una BOZZA (draft) di lavoro non è un documento stabile.

Se si legge il requisito parla chiaro: “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.” HTML5 non è ancora una grammatica formale pubblicata ma è una bozza di lavoro.

Ma su http://www.whatwg.org/ ci sono già le specifiche…

Stiamo parlando di HTML5 e HTML5 è W3C, non è WHATWG. WHATWG è entrato nel W3C esclusivamente per portare avanti la specifica con valore normativo, il che significa non solo riconoscimento da parte di governi ma soprattutto da parte dei produttori di tecnologie che consentono lo sviluppo e la lettura delle nuove specifiche. Il W3C non è formato da politici ma da tecnici: basta che apri qualsiasi specifica e/o bozza di specifica per vedere che nei gruppi di lavoro ci sono persone che lavorano per creare un web migliore, condiviso e – nell’ottica di chi ha fondato il Web – accessibile a tutti.

L’atteggiamento invece del WHATWG è quello di persone che pensano di rappresentare il “mercato” e propongono le loro cose fottendosene di tutto il resto. Il W3C è lento? Quella che viene chiamata lentezza si chiama percorso di approvazione di una specifica, condiviso a livello internazionale. Pensate che l’ISO invece ha tempi ben superiori perchè – quando votiamo documenti ISO – rappresentiamo delle nazioni e non le nostre associazioni.

Stranamente se parliamo di accessibilità vedete che le WCAG 2.0 hanno dato modo di porre il W3C davanti alle tecnologie in quanto i produttori di singole tecnologie stanno implementando tecniche di applicazione consone a garantire un accesso a tutti. Per WHATWG HTML5 va bene così: peccato che quando sono entrati nel gruppo di lavoro del W3C hanno accettato le regole tra cui la necessità che la specifica passi il vaglio del protocols and formats working group, un gruppo che verifica che una specifica non vada in contrasto con un’altra. Per quello li chiamo cazzari: saper fare “web” non significa saperne fare le specifiche: sono due mestieri differenti e pretendere di fare il mestiere di altri senza conoscere ciò a cui si va incontro (per le specifiche non si può fare la eternal beta… se sbagli un DTD poi mica puoi patcharlo nel giro di 5 minuti…) e vorrei sapere quanti di loro conoscono queste specifiche: http://www.w3.org/TR. Fare fa rima con normare ma son due cose differenti. Spero che sia chiaro

La conclusione del nostro percorso è che: fare un sito in HTML5 si può benissimo fare. Studiarne le specifiche, applicarle sui nostri siti, si può benissimo fare poichè a quanto pare la tecnologia dei browser si è già portata avanti. Non è professionale però applicarle sui siti dei nostri clienti, a maggior ragione se sono Pubbliche Amministrazioni (la normativa parla chiaro): state infatti creando un sito “non a norma” e rischiate di dover rifare tutto o in parte una volta che la draft diventerà una specifica approvata.

Applicare HTML5 si può fare studiando le bozze del W3C, almeno su questo siamo d’accordo. Se osservate, l’ultima, ad oggi, è datata 5 aprile 2011: come si fa a starle al passo senza sbagliare e dover rifare tutto fra un mese? Inoltre il fatto che per usarlo non bisogna inserire alcun doctype ha inizio pagina dovrebbe dirvi già molte cose.

L’entusiasmo su questa nuova possibile specifica è tanto, lo comprendo, ma dato che siamo umili sviluppatori e webdesigner che non facciamo parte né del W3C né lavoriamo nelle società di software che creano i browser sui quali navighiamo (e che potrebbero, paradossalmente da un giorno all’altro rilasciare una versione del browser completamente incompabile con HTML5, proprio perchè ancora in draft), invito tutti a rimettersi a quanto “Papà W3C” ci definisce come standard, in pace con tutti. Qui non si è mai detto che HTML5 è demonio, ma semplicemente che ancora non è una specifica. Tornate al 1999 e fatemi vedere una statistica dei siti creati in xhtml 1 quando ancora questo era in bozza: non credo ci fosse niente da discutere, i siti online erano tutti ancora HTML4.

E con ciò, andiamo in pace XD

Come accennato però la Legge Italiana prevede 22 requisiti, che andremo a seguire e imparare, e per far ciò vedrò di renderveli appetibili e leggeri.

I requisiti sono ben spiegati sul sito Webaccessibile.org. Li riassumiamo considerando unicamente la parte riguardante la creazione di nuovi siti presupponendo che vi sarà sempre comunque richiesto un restyling totale del sito e non una “bonifica” di quello esistente. Commentiamoli insieme.

Requisito 1

Realizzare le pagine utilizzando le specifiche più recenti del W3C, rispettandone l’aspetto semantico.

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;

Scordatevi pertanto html5, poichè sottolineo, non è ancora uno standard.

E scordatevi anche gli stili in linea e target=”_blank”

Fin qui mi sembra che ci siamo no? Non è poi così complicato E’ sufficiente una validazione sul sito del W3C per valutare come √”fatto” il primo requisito

Andiamo al secondo punto:

Requisito 2

Non è consentito l’uso dei frame nella realizzazione di nuovi siti. In sede di prima applicazione.

Vi state chiedendo perchè vero? Ebbene, i motivi sono due:

1. 1.provate a guardare il codice della pagina che state navigando: seppure voi vediate contenuti diversi a seconda dei click sul menu, in realtà è solo il frame centrale che sta cambiando, ma la pagina, guardate bene, è solo una composizione di tag che richiamano le pagine, e non vi sono contenuti. Immaginate quanto sia frustrante per una persona che legge i siti tramite screen reader perchè non vedente e immaginate quanto controproducente sia per Google, che indicizzerà invece le singole pagine che compongono la homepage. E qui si va al secondo motivo:
2. 2.vi è mai capitato di cercare su Google qualcosa e di finire su una pagina senza menu di navigazione nè titolo? Ecco cosa succede al vostro sito: viene indicizzata solo la pagina con i contenuti, e dopo averla consultata l’utente la abbandonerà inevitabilmente poichè innavigabile.

Alla prossima per i successivi punti

L’accessibilità è la caratteristica di un dispositivo, di un servizio o di una risorsa d’essere fruibile con facilità da una qualsiasi tipologia d’utente.

Il termine è comunemente associato alla possibilità anche per persone con ridotta o impedita capacità sensoriale, motoria, o psichica (ovvero affette da disabilità sia temporanea, sia stabile), di fruire dei sistemi informatici e delle risorse a disposizione.

Il termine ha trovato largo uso anche nel settore di Internet col medesimo significato.

Questo tipo di attenzione nello scrivere codice deve seguire delle linee guida, redatte dal già noto W3C nelle WCAG 2.0 (2008), rese obbligatori per legge in tutto il mondo con le rispettive regolamentazioni redatte dai vari paesi.

In Italia il tutto è stato regolamentato con la Legge Stanca del 2004 che riassume in 22 requisiti obbligatori le WCAG. Questa regolamentazione riguarda i siti web creati per le pubbliche amministrazioni (siti di associazioni e società amministrate e gestite da Governo, Regioni, Comuni, etc), ma se tutti seguissero queste linee guida volontariamente per i propri siti, ne trarrebbe vantaggio certamente tutta la società.

E’ molto diffuso infatti l’immaginario dell’omino in carrozzella che non può usufruire di internet…ma pensateci bene: una persona invalida nelle gambe può navigare su internet, eccome! Allora chi sono gli invalidi del web? Sono più comuni e vicini di quanto si pensi, e pertanto non vanno sottovalutati: handicap manuali (anche temporanei-provate a usare il mouse o la tastiera con un braccio ingessato), ridotte capacità motorie (anziani, malattie neuronali) o visive (daltonismo, disturbi percettivi o di campo visivo, epilessia)…persino le persone con cecità al 100% possono navigare e usufruire di internet se il sito è fatto con tutti i crismi. Perchè vietarglielo?

Al contrario della validazione del codice xhtml e css, che pure fanno parte di questo processo di conformità, non esiste un validatore delle linee guida di accessibilità, sarebbe troppo comodo.
Infatti molti requisiti non sono rilevabili in modo così automatico come ci si aspetterebbe, ma dobbiamo attenerci ai 22 requisiti con scrupolosità. Sta poi ad un ente particolare indicato a far ciò, valutare la conformità del sito creato. Questo ente si chiama Cnipa Digitpa ed è l’unico autorizzato a rilasciare certificati di conformità ai requisiti, ed il livello di conformità raggiunto (A – AA oppure AAA).

Da sottolineare che per “sito accessibile” non si intende solo un sito che sia fruibile da queste categorie protette, ma anche che sia visibile da qualsiasi tipo di dispositivo. Con l’avvento infatti dei dispositivi mobili, il termine “accessibilità” si è allargato a questa fascia di utenti, che dispongono di telefonini di ultima generazione o iPad, che hanno quindi requisiti di risoluzioni, aree di click e tecnologie particolari. Ma non sono contemplati nei 22 requisiti che andremo a vedere, ne parleremo nelle sedi opportune.

Vogliamo vedere insieme quali sono questi requisiti? Bene, dalla prossima volta li analizzeremo uno per uno. Qualche dubbio nel frattempo?