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

“Ma la musica è d’effetto, ci vuole per il mio sito supercool!” o “Il mio sito è quello di una discoteca, ci vuole il giusto background emotivo!” o ancora “Il mio sito di filosofia zen ha bisogno del giusto mood di accompagnamento!“. Risposta: NO.

Perchè?

1. Se l’utente vuole ascoltare della musica, avrà già la sua di sottofondo, e sentire una musica che si sovrappone con sgradevole cacofonia alla propria è irritante. Ancor peggio se si trova in un ufficio o luogo di lavoro e gli parte la musica: chiuderà instantaneamente il sito!
2. L’utente potrebbe avere gli altoparlanti disabilitati (vedi: uffici, luoghi pubblici, biblioteche o per volontà propria perchè desidera silenzio): prettamente inutile e rallenta il caricamento della pagina.
3. L’utente è un nerd che visita più pagine contemporaneamente, o ancora sta scegliendo una discoteca/locale/ristorante: indovinate qual è il sito che verrà chiuso perchè si sovrappone alla sua musica se non quella degli altri siti? e indovinate su quale si soffermerà? bravi. non il vostro.
4. Infine, se il sito è un sito di multimedia, video, o di un cantante/musicista, diamo comunque la scelta all’utente di scegliere quando sentire la musica, se vuole. Non è detto che stia visitando il sito perchè vuole ascoltare la musica del cantante che già ben conosce, ma perchè vuole vedere le date dei suoi prossimi concerti!
5. Infine ma non ultimo: bisogna pagare i diritti alla SIAE per tutto il periodo in cui rimarrà online se non si è titolari dei diritti sulla canzone pubblicata!

Questo libro è alla sua terza versione, io avevo la seconda, ma questa è completamente riscritta ed aggiornata alle novità degli ultimi anni della rete, dai social network, a tipi di sito che non erano neanche lontanamente pensabili nel 2004, anno della redazione della versione 2.

Gioisco e salto sulla sedia quando leggo parole che vorrei poter esprimere io stessa quando spiego certi concetti, ma Sofia lo sa far bene e meglio di me. I concetti che mi affollano la mente sono tanti, e nel libro sono tutti spiegati ed argomentati. Sentitevi liberi di criticarli, ma vedrete, ad un semplice test di usabilità, quanto sono veri!

Condivido particolarmente il pensiero a pagina 48 sui grafici che si vantano di voler essere creativi e abbattere la barriere con idee non convenzionali, salvo poi avere un sito bellissimo ma perfettamente inusabile. Non avrebbe potuto spiegare meglio i perchè e i come, ed invito tutti i grafici a leggerlo. Se volete ve lo presto io!

Detto questo: buona lettura!

• Un capitolo di “Siti che funzionano 3.0″, in questi giorni in libreria
• Chi è Sofia Postai
• Acquista presso l’editore – IBS o Amazon cliccando qui sopra

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!!

Oltre al mio parere, quelli di:

• Annalisa Riggio di EpidemiaLab
• Mirko D’Isidoro di Blographik
• Tommaso Baldovino di Tomstardust
• Francesco Gavello di FrancescoGavello
• Sara Presenti di YourInspirationWeb
• Antonio Fullone di AntonioFullone
• Massimo Mastromarino di DesignMultimedia

Grazie ancora a Julius (a cui ho preso anche in prestito l’immagine di presentazione dell’articolo)!

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