Queste indicazioni hanno un obiettivo ben preciso, dichiarato nel testo di presentazione:

[...] suggerire alle PA criteri e strumenti per la riduzione dei siti web pubblici obsoleti e per il miglioramento di quelli attivi, in termini di principi generali, modalità di gestione e aggiornamento, contenuti minimi. A tal fine, le Linee guida sono finalizzate a delineare gli aspetti fondamentali del processo di sviluppo progressivo dei servizi online e di offerta di informazioni di qualità rivolte al cittadino, che deve contraddistinguere ogni pubblica amministrazione.

Sono stupito (ma forse non troppo) nel vedere che purtroppo le novità e le differenze rispetto alle linee guida del 2010 sono state pubblicate in un’immagine .jpg, deformata ma soprattutto inaccessibile. Se nemmeno in questo ambito vengono rispettati i minimi requisiti, non mi sorprende che ancora oggi buona parte della rete sia preclusa ad una buona fascia di utenti.

L’invito è sempre lo stesso: preoccupatevi delle normative, ma pensate all’accessibilità reale dei siti che realizzate, e soprattutto considerate l’applicazione di certe buone norme nel lavoro di tutti i giorni, non solo lavorando nell’ambito della PA.

Una di queste situazioni è stata descritta pochi giorni fa su 456 Berea Street, e riguarda le liste HTML: i classici tag <ol> e <ul>. Quando l’aspetto della lista viene nascosto tramite fogli di stile, molti screen reader non la annunciano come tale, anche se il codice HTML dice il contrario.

Questo si verifica utilizzando gli attributi CSS:

list-style-type: none

oppure

list-style: none

In questi casi NVDA su Firefox, Orca e VoiceOver non dichiareranno la presenza di una lista. Non è un problema gravissimo, ma questo comportamento peggiora l’esperienza di navigazione degli utenti che usano uno screen reader. Non saranno infatti in grado di capire quando inizia o finisce un elemento.

Una informazione del genere ovviamente va valutata a seconda delle situazioni e del target di utenti: nessuno vi impedisce di usare list-style: none, ma se lavorate su un sito dove tenete all’accessibilità, considerate l’ipotesi di mostrare le liste come tali, senza ricorrere a immagini in background per i puntatori o stratagemmi simili.

Se vi interessa approfondire l’argomento screen reader e volete testare il vostro sito, trovate altre informazioni utili in questo post: Uno screen reader per i test.

Il primo è usare l’attributo “for” sulla label, con un valore corrispondente all’id dell’elemento associato:

<label for="email">email:</label>
<input type="text" id="email" />

Il secondo è inserire il campo del form all’interno della label:

<label>email: <input type="text" /></label>

Personalmente preferisco il primo metodo, ma il secondo è comunque valido e riconosciuto come corretto.

Label nascoste

Un metodo molto diffuso ultimamente è quello di non visualizzare la label, inserendo un placeholder all’interno del campo, o usando JavaScript per nascondere al clic un valore che fa da segnaposto, come il classico “inserisci qui la tua email”.

Questa tecnica può essere tranquillamente utilizzata, ma non autorizza ad eliminare l’etichetta associata. La label deve essere sempre presente, anche se invisibile.

HTML5 e le label

Parlando di HTML5, il discorso è più o meno analogo. C’è un interessante articolo di Steve Faulkner sull’argomento con alcuni test pratici: HTML5 accessibility chops – form control labeling.

Dai risultati si nota come il metodo più sicuro per far riconoscere una label al browser (o a una tecnologia assistiva come uno screen reader) sia sempre l’attributo for abbinato ad un id.

Un altro metodo efficace è l’utilizzo dell’attributo aria-labelledby, che viene riconosciuto come valido:

<label id="email">email</label>
<input type="text" aria-labelledby="email">

Inserire il campo input all’interno di una label non è un metodo pienamente supportato, quindi con HTML5 è meglio evitarlo, almeno per ora.

Creare un form accessibile non è complicato, seguendo queste poche indicazioni avete tutti gli elementi per utilizzare correttamente le label. La cosa importante è ricordarsi di avere sempre un minimo di attenzione ai dettagli. Basta veramente poco per rendere un form accessibile, con qualsiasi specifica.

Esistono vari modi di ridimensionare il testo di una pagina web tramite CSS: in pixel, em e in percentuale.

Tramite un post di Jonathan Snook ho scoperto l’esistenza di una nuova unità di misura introdotta con i CSS3, chiamata rem. Questa unità si comporta in maniera molto simile a em, senza ereditarne i punti deboli.

Font-size con em

Prima di parlare delle novità mi sembra giusto riprendere in mano la tecnica che potrebbe essere sostituita.

Utilizzare l’unità di misura em permette già ora di superare un problema di tutte le versioni di Internet Explorer (compresa la 9): l’impossibilità di ridimensionare il testo quando il font-size è espresso in px. Con em questo inconveniente non esiste, basta usare una formula di questo tipo:

body { font-size:62.5%; }
h1 { font-size: 2em; } /* =20px */
p  { font-size: 1.4em; } /* =14px solo se non all'interno di una lista */
li { font-size: 1.4em; } /* =14px solo sul primo livello */

Il problema però è che em è un’unità di misura relativa all’elemento contenitore. Se nella pagina appare un paragrafo all’interno di un elemento li oppure ci sono due o più liste annidate, gli elementi interni aumentano progressivamente di dimensione. Una lista contenuta in un’altra lista in questo caso non sarebbe più 14px ma 20px. Aumentando di un altro livello la dimensione del testo diventerebbe 27px.

Il problema può essere evitato dichiarando per ogni livello il font-size originale, ma è un metodo scomodo e poco mantenibile.

Font-size con rem

L’unità di misura rem si comporta come em, ma fa riferimento all’elemento alla radice del documento. Rem infatti è la sigla per “root em”.

La nuova formula diventa:

html { font-size:62.5%; }
h1 { font-size: 2rem; } /* =20px */
p  { font-size: 1.4rem; } /* =14px */
li { font-size: 1.4rem; } /* =14px */

In questo modo tutti i problemi sono risolti, non esistono differenze sugli elementi annidati e il testo può essere ridimensionato senza problemi anche su IE.

Rem e il supporto dei browser

Il supporto di questa unità di misura è migliore di quanto pensassi: viene riconosciuta da tutte le ultime versioni dei browser, escluso Opera. Per non avere problemi su questo browser e garantire il supporto anche alle versioni precedenti di IE è sufficiente indicare un fallback nei CSS:

html { font-size:62.5%; }
h1 { font-size: 20px; font-size: 2rem; } /* =20px */
p  { font-size: 14px; font-size: 1.4rem; } /* =14px */
li { font-size: 14px; font-size: 1.4rem; } /* =14px */

Cosa ne pensate? Io inizierò a sperimentare questa tecnica nei miei prossimi progetti, e se non emergeranno particolari problemi penso proprio che potrebbe diventare uno standard. E’ più immediato utilizzare px come unità di misura, ma se tenete all’accessibilità dei vostri lavori basta veramente poco per fare la differenza.

[Foto di Paul Pirosca - Fotolia.com]

PhpBB è una piattaforma molto diffusa per la gestione di forum online. La risorsa che voglio segnalare oggi è un tema accessibile per phpBB realizzato da uno sviluppatore italiano: Francesco Carzedda.

Accessibile (Accessible nella versione inglese) è il primo tema per phpBB che rispetta la nostra legge Stanca (4/2004) e le più recenti WCAG 2.0: non ho trovato altre risorse simili disponibili gratuitamente, e questo fa onore al lavoro di Francesco che ha deciso di distribuire il suo lavoro in rete.

Il tema è derivato da Prosilver ed è liberamente utilizzabile e modificabile. La semantica è ottima, e potete modificare l’aspetto grafico senza problemi come preferite: attenzione comunque a continuare a rispettare le linee guida sull’accessibilità.

La parola all’autore del tema

Ho approfittato dell’occasione per chiedere a Francesco cosa l’ha spinto a realizzare questo tema e come è arrivato ad interessarsi a certe tematiche. L’attenzione per l’accessibilità è un argomento ancora troppo sottovalutato, ed è fondamentale valorizzare chi decide di impegnarsi in questo ambito.

Ciao Francesco, come sei arrivato a realizzare questo tema?

Nel 2003/4 ho seguito un percorso di specializzazione nella Formazione (modalità E-learning) che focalizzava anche il problema dell’accesso dei disabili alle tecnologie.

Con l’inizio della mia esperienza nel volontariato, ho individuato due binari: il Soccorso e l’Accessibilità web.

Il mio spazio web 4elementi è nato come palestra per l’obiettivo di popolare il web con sviluppi accessibili nella speranza di sensibilizzare e – grande regalo – di incontrare sensibilità come la tua.

Così sono nati il sito, il blog ‘fatto a mano’, il tema per WordPress (attualmente base per un progetto di turismo accessibile), il template per Joomla (modestia a parte molto completo) e finalmente lo style per PhpBB (da affinare nel layout ma di solido impianto semantico e sviluppato lasciando per ultima la presentazione visuale).

Tengo a precisare che tutto ciò si svolge a titolo di volontariato, non ho competenze di sviluppatore tali da farmi pensare a un esito professionale in quel senso, inoltre la motivazione che mi anima non segue i ritmi di un’attività lavorativa.

Download e demo

Potete scaricare il tema per phpBB e provare una demo sulle seguenti pagine:

• Download
• Demo

WebAIM

Quest’anno le novità sono interessanti, ed è molto utile poter fare un confronto con i risultati degli anni passati per capire l’andamento di alcune tendenze. Tra i dati principali:

• JAWS si conferma il lettore di schermo più usato, ma la sua diffusione è in calo. In forte crescita l’open source gratuito NVDA, che passa dal 3% al 9%.
• Il 20% degli utenti non ha aggiornato lo screen reader nell’ultimo anno.
• Internet Explorer in tutte le sue versioni rimane il browser più utilizzato, ma rispetto al 2009 è in calo mentre salgono Firefox 3+ (da 18,8% a 23,5%) e Safari (da 8,3% a 9,6%). IE6 è in via di estinzione, da 12,7% a 5,2%.
• JavaScript è ormai indispensabile anche per gli utenti di screen reader: solo l’1,6% lo disabilita.
• La diffusione degli smartphone con lettore di schermo è in continuo aumento: si passa dal 53% al 66,7%.
• Il 49,5% non ha idea di cosa sia HTML5, ma il 33,7% crede che la nuova specifica porterà dei miglioramenti all’accessibilità del web.
• Il 39,5% utilizza almeno saltuariamente i landmark ARIA per spostarsi in una pagina web, ma la diffusione di questa tecnologia è ancora scarsa.
• Le intestazioni e gli skip link continuano ad essere utilizzati come metodo di navigazione delle pagine.

Nonostante la grande quantità di informazioni è possibile ricavare alcuni dati interessanti. Una delle cose più importanti è la grande diffusione di JavaScript su cui ha scritto un bell’intervento anche Bruce Lawson: ormai è diventato uno standard, ma questo non significa smettere di preoccuparsi del comportamento dei siti web con JavaScript disabilitato.

Trovate i risultati completi del sondaggio sul sito ufficiale di WebAIM: Screen Reader user survey #3.

E’ una novità molto comoda che permette di evitare l’uso di JavaScript, ma deve essere utilizzata con attenzione. La prima cosa da notare è che il placeholder non sostituisce la label.

Le specifiche del W3C dicono:

The placeholder attribute should not be used as an alternative to a label.

Per andare sul sicuro vi consiglio di considerare il suggerimento un più rigido divieto: l’attributo placeholder non deve essere un’alternativa alla label.

Altro punto riguarda il contrasto tra testo e colore di sfondo: quello di default non è sufficiente per superare i test di accessibilità. Al momento è possibile modificare il colore del placeholder su Chrome, Safari e Firefox 4 in questo modo:

input::-webkit-input-placeholder {color: #555;} /* Webkit browsers */
input:-moz-input-placeholder {color: #555;} /* Firefox 4 */

Il supporto non è ottimale, ma per fare delle verifiche potete fare riferimento a questi browser:

• Chrome, Safari e gli altri browser Webkit
• Firefox 4
• Opera (che però non consente ancora di modificare lo stile CSS dell’attributo)

Se volete testare personalmente il funzionamento dell’attributo placeholder potete accedere a questa pagina di test, ricordando di utilizzare uno dei browser citati:

Demo: Placeholder

Anche questa volta sono stato coinvolto direttamente con un articolo su web design e daltonismo su cui mi farà molto piacere ricevere i vostri pareri. Avevo già affrontato l’argomento su questo blog, ma rimanevano ancora varie cose da sottolineare e questa mi è sembrata un’ottima occasione per poter parlare di accessibilità ad un più ampio numero di lettori.

In questo numero di YIM sono tanti gli articoli da leggere: dedicate un po’ di tempo a sfogliare la rivista e se vi piacciono i contenuti condividetela tra i vostri amici e conoscenti.

Link: Your Inspiration Magazine – Numero 3

Questo articolo non vuole essere promozionale: vedere come si comporta un utente di screen reader con in mano un dispositivo touchscreen è sempre utile, soprattutto per chi si occupa di accessibilità. E’ fondamentale anche per avere un riferimento concreto al mondo reale: fa sempre bene studiare la teoria, ma soprattutto in questo settore è l’esperienza sul campo che fa la differenza.

Qualche giorno fa l’argomento è stato affrontato anche su Melablog: è interessante vedere come certe tematiche inizino ad acquisire la necessaria importanza.

Le gesture di VoiceOver su iPhone

L’iPhone 3GS è stato il primo dispositivo Apple touchscreen ad introdurre VoiceOver.

Il lettore di schermo consente in ogni momento di sapere cosa sta succedendo: spostando il dito sullo schermo ogni icona o elemento viene letto ad alta voce, e per potere interagire è necessario fare un doppio tap. C’è però un’obiezione che viene spontanea: come può un utente non vedente sapere dove sono posizionate delle icone o degli elementi se non li ha mai visti prima?

La domanda è legittima, ed infatti questa non è l’unica modalità di utilizzo di VoiceOver. Scorrendo velocemente un dito sullo schermo è possibile infatti passare da un elemento al successivo: ad esempio scorrere tutte le icone della dashboard.

Per le azioni come il passaggio alla pagina seguente arriva in aiuto il multitouch: scorrendo tre dita sullo schermo si arriva alla seconda schermata della dashboard. I gesti sono ovviamente differenti quando VoiceOver è attivo, perché c’è la necessità di mappare una vasta serie di comandi da eseguire velocemente con una o due dita.

Esiste inoltre la possibilità di associare VoiceOver al tasto home: tre clic e l’iPhone torna alle sue impostazioni standard, altri tre clic e lo screen reader viene riattivato.

I miglioramenti introdotti da iPad

Con l’arrivo dell’iPad l’esperienza d’uso di VoiceOver è migliorata: ci sono infatti piccoli cambiamenti che portano l’usabilità del touchscreen ad un livello superiore.

Un esempio?

Quando appare sullo schermo la tastiera virtuale, prima era necessario scorrere il dito sullo schermo fino a trovare il carattere desiderato e poi fare un doppio tap per inserirlo. Adesso è sufficiente solo la prima azione, perché il carattere viene inserito non appena il dito lascia il touchscreen.

Un altro miglioramento riguarda la possibilità di ruotare lo schermo. Su iPhone, VoiceOver non descriveva in alcun modo se lo schermo fosse in modalità portrait o landscape. Con l’iPad non solo viene descritto l’orientamento, ma anche la posizione del tasto home, che essendo l’unico tasto fisico sulla superficie viene spesso usato come punto di riferimento.

Il video

In casi come questi un video può essere molto utile per capire come un non vedente utilizzi VoiceOver. Russ Weakley e Roger Hudson proprio per questo motivo hanno registrato una breve sessione con l’aiuto di David Woodbridge.

Il video è in inglese, dura circa 8 minuti ed è sottotitolato in varie lingue. Potete abilitare i sottotitoli direttamente dal player, e trovate la trascrizione completa nel post originale.

Un altro elemento da considerare è che VoiceOver usa le stesse gesture su Mac, iPhone e iPad. Se ne avete la possibilità, provate a navigare una pagina web con VoiceOver attivato e capirete molto su come deve essere un sito accessibile.

Se l’argomento vi interessa, potreste trovare interessanti anche le considerazioni fatte con Elena Brescacin, una sviluppatrice non vedente che ho intervistato qualche tempo fa, ed il racconto (in inglese) di Austin Seraphin dopo una settimana di utilizzo dell’iPhone con VoiceOver.

Come funzionano gli access key?

Associando ad un elemento di tipo a, area, button, input, label, legend e textarea l’attributo accesskey=”…” , è possibile indicare al browser una scorciatoia per raggiungere quell’elemento. Generalmente per utilizzare l’access key è necessario premere alt in combinazione con il tasto indicato.

I problemi degli access key

Il problema fondamentale è che non è mai stato definito uno standard su quali elementi di un sito debbano essere raggiungibili tramite access key. Considerando poi che non esiste nemmeno una regola su quali lettere utilizzare, il risultato è decisamente caotico.

Non solo un utente dovrebbe imparare per ogni sito degli access key diversi, ma potrebbe anche trovare dei conflitti con altre scorciatoie già definite dal sistema. Ogni browser infatti ha delle abbreviazioni predefinite per accedere ai menu (File, Modifica, ecc…), ed ognuno di loro si comporta in maniera diversa: in certi casi gli access key hanno la precedenza, in altri no.

Un altro fattore da considerare è che gli utenti utilizzatori di screen reader utilizzano molte altre scorciatoie, anche queste da aggiungere alla lista.

Inserire degli access key in una pagina non assicura quindi la possibilità di raggiungere velocemente determinati link, ma potrebbe aumentare la confusione. Se siete interessati ad approfondire il discorso, vi consiglio di leggere parte del capitolo 14 del libro “Accessibilità: guida completa” di Michele Diodati, dove questi problemi vengono descritti ampiamente. Il testo è di qualche anno fa ed alcuni esempi non sono aggiornati, ma è ancora oggi utilissimo.

Come fornire delle scorciatoie?

E’ comunque importante fornire dei metodi per muoversi all’interno di una pagina anche senza mouse. La soluzione migliore, ormai largamente diffusa, è quella di inserire degli skip link per saltare al contenuto principale di una pagina o al menu di navigazione. Solitamente queste scorciatoie sono posizionate ad inizio pagina, nascoste via CSS, e permettono a chiunque di andare immediatamente al contenuto desiderato.

Una soluzione di questo tipo è inserita anche nelle tecniche consigliate per adempiere al punto 2.4.1 delle WCAG 2.0.

La possibilità di utilizzare gli access key rimane, ma da requisito è passata a suggerimento: considerando i possibili problemi il mio consiglio è di trovare soluzioni alternative e non utilizzarli. Su questo sito ad esempio è presente uno skip link per saltare al contenuto, visibile anche premendo il tasto tab dopo il caricamento della pagina.

[foto di alcomm]